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ABSTRACT 


/ 

/ 


\  /  Potomac  Systems  Engineering,  Inc.  (PSE),  is  providing  Independent  Verification  and 
Validation  (IV&V)  support  to  the  Special  Assistant  for  Model  Validation,  U.S.  Army 
Concepts  Analysis  Agency  (CAA),  during  the  design  and  development  of  the  Global 
Deployment  Analysis  System  (GDAS).  The  primary  objective  of  this  effort  is  to  help  ensure 
that  development  of  the  GDAS  results  in  a  model  that  will  perform  as  intended.  This 
report  summarizes  the  IV&V  support  provided  by  PSE  during  the  system  implementation 
phase  (Phase  II). 

Development  of  the  GDAS  is  a  24-month  project,  to  be  executed  in  three  phases  by  Stanley 
Associates,  Inc.,  of  Alexandria,  Virginia.  Phase  I  was  a  9-month  design  phase  during  which 
the  model  developer  detailed  a  specific  approach  to  the  GDAS  design  and  prepared  a 
prototype  model  containing  specific  features  planned  for  implementation  in  the  final  GDAS 
model.  GDAS  development  is  approaching  completion  of  Phase  11  (implementation)  and 
will  end  with  Phase  Ilf  (integration,  testing,  and  acceptance). 

The  IV&V  support  provided  by  PSE  during  Phase  I  and  Phase  11  contributed  to  the  quality 
of  the  GDAS  design,  documentation,  and  GDAS  software  produced  to  date.  A  sound 
IV&V  program  can  ensure  that  the  quality  of  the  model  software  is  established  early  in  the 
development  phase  and  that  this  level  of  quality  is  maintained  and  increased  as  the  software 
is  tested,  transitioned  to  the  users,  and  entered  into  the  operations  and  support  phase  of  the 
life  cycle.  It  can  also  promote  an  efficient  design,  quality  code  development,  complete 
functionality,  realistic  data  requirements,  run-time  efficiencies,  and  effective  human  factors 
engineering. 
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SECTION  1.  INTRODUCTION 


1.1  Global  Deployment  Analysis  System  (GDAS)  Overview 

Development  of  the  GDAS  is  the  flrst  step  in  developing  an  extensive  automated  data 
processing  (ADP)  system  that  will  evaluate  the  capabilities  and  requirements  of  Department 
of  Defense  mobilization  and  deployment  systems,  and  will  also  provide  input  to  combat 
models  at  the  U.S.  Army  Concepts  Analysis  Agency  (CAA).  CAA  is  a  Field  Operating 
Agency  functioning  under  the  jurisdiction  of  the  Director  of  the  Army  Staff.  As  part  of  its 
mission,  CAA  must  evaluate  the  Army’s  operational  capability  to  mobilize;  deploy  forces; 
and  conduct  unilateral,  joint,  and  combined  operations  in  various  theaters  of  operations. 
CAA  uses  computer  models,  simulations,  and  other  ADP  tools  and  techniques  to  determine 
strategic  mobility  capabilities  and  requirements  supporting  several  Defense  Guidance 
objectives. 

CAA’s  Transportation  Model  (TRANSMO)  has  been  the  primary  tool  providing  data  for 
deployment  analyses.  Over  the  past  several  years,  the  advent  of  CAA’s  Force  Evaluation 
Model  (FORCEM)  as  its  primary  theater  campaign  simulation,  combined  with  requirements 
for  such  studies  as  the  Ultra-Fast  Sealift  Study  (UFSS)  and  the  Army  Strategic  Mobility 
System  Assessment  (ASMSA),  have  clearly  established  the  need  for  an  improved 
deployment  model. 

In  1987,  CAA  conducted  an  internal  study,  the  Transportation  Evaluation  Research  Project 
(TERP),  which  examined  the  overall  CAA  strategic  mobility  process  supporting  a  wide 
range  of  studies.  TERP  determined  requirements  for  the  CAA  transportation  analytical 
process  and  examined  various  models  as  possible  alternatives  to  TRANSMO.  None  of  the 
candidate  models  met  all  CAA’s  requirements,  so  a  major  TERP  recommendation  was  that 
CAA  pursue  the  acquisition  of  a  new  model  to  simulate  both  intertheater  and  intratheater 
transportation. 

The  GDAS  project  addresses  only  the  intertheater  transportation  systems.  Its  objective  is 
to  provide  a  set  of  automated  tools  for  detailed  transportation  analysis  that  will  also  furnish 
deployment  data  to  support  combat  simulation  models.  CAA  has  published  GDAS 
requirements  in  a  report  entitled  "Strategic  Transportation  Analytical  Requirements 
(STARS):  Functional  Description  of  a  Global  Deployment  Analysis  System."  Ultimately, 
the  intended  larger  system  of  which  the  GDAS  is  a  part  will  simulate  the  mobilization  of 
U.S.  forces,  deployment  of  forces  and  supplies  across  an  intertheater  network,  and 
deployment  of  forces  and  supplies  to  the  combat  zone. 

12  Phast  U  lY&V  SummaiT 

Potomac  Systems  Engineering,  Inc.  (PSE),  is  providing  IV&V  support  to  CAA  during  the 
GDAS  development  project.  Phase  n  (implementation)  was  a  12-month  effort  in  which  the 
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model  developers  coded  and  integrated  computer  software  in  accordance  with  the  GDAS 
System  Design  Specifications  resulting  from  Phase  I.  PSE  independently  evaluated  the 
prototype  software  and  documentation  provided  to  CAA  by  the  model  developers. 
Feedback  from  PSE  to  CAA  on  each  item  evaluated  provided  clear,  objective  statements 
of  actual  software  capabilities  and  of  deficiencies  in  content  or  function  that  could  negatively 
impact  the  outcome  of  the  GDAS  development  project.  This  report  summarizes  the  FV&V 
work  done  by  PSE  during  GDAS  Phase  II. 

U  Definitions 

Verification  is  the  process  of  determining  that  a  model  represents  its  conceptual  description 
and  specifications.  It  is  a  continuing  effort  that  reveals  errors,  omissions,  and  potential 
hazards  early  in  the  development  process  when  errors  are  less  expensive  to  correct. 
Verification  involves  evaluation  and  analysis  to  determine  model  consistency,  completeness, 
and  adequacy  at  each  level  of  development. 

Validation  is  the  process  of  determining  that  a  model  accurately  represents  the  intended 
system.  During  the  development  of  a  model,  validation  is  best  accomplished  by  establishing 
that  the  system  achieves  its  specified  functional  and  performance  levels  from  the  subsystem 
level  to  the  fully  integrated  system  in  a  reliable  and  efficient  manner.  This  may  include 
comparing  results  from  separable  module's  or  from  the  overall  model  with  those  from  real- 
world  entities,  other  verified  and  validated  models,  test  and  exercise  data,  or  historical 
observations. 
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SECTION  2.  DISCUSSION  OF  GDAS  PHASE  II  IV&V  ACTIVITIES 


2.1  General 

PSE  is  helping  the  government  identify  and  resolve  potential  GDAS  development  problems 
as  early  as  possible  to  minimize  the  cost  impact  on  the  GDAS  development  program  and 
to  rapidly  assess  the  actual  capabilities  of  delivered  system  prototypes.  Experience  has 
demonstrated  that  problems  discovered  late  in  a  program,  such  as  during  the  software 
integration  and  test  phase,  are  very  expensive  to  correct.  Some  potential  problems  can  be 
averted  through  independent  evaluation  of  the  development  specifications  and  by  objective 
analysis  of  high-risk  areas  to  help  the  government  determine  whether  the  solutions  proposed 
by  the  software  development  contractor  are  adequate  and  cost-effective.  Independent 
monitoring  of  the  development  process  also  helps  to  identify  hardware  and  software 
inconsistencies  as  they  occur,  thus  minimizing  the  time  and  resources  expended  in  correcting 
such  inconsistencies. 

PSE’s  IV&V  objectives  during  the  GDAS  implementation  phase  (Phase  II)  were  to: 

o  Develop  a  GDAS  Phase  II  IV&V  management  plan 
o  Exercise  and  evaluate  GDAS  prototypes 

o  Review  GDAS  documentation 

o  Support  and  participate  in  GDAS  program  reviews 
o  Track  GDAS  developmental  activities. 

These  objectives  correspond  to  the  tasks  established  in  the  Delivery  Order  for  GDAS 
Phase  II  IV&V  efforts.  Activities  and  results  supporting  each  Phase  II  objective  are 
summarized  in  the  following  subsections. 

22  Independent  Verification  and  Validation  Management  Plan  flWMP) 

The  GDAS  IWMP  is  a  description  and  schedule  of  GDAS  IV&V  activities  that  is  more 
detailed  than  the  documents  comprising  the  basic  contract  for  the  IV&V  project.  It  reflects 
government  schedules  and  priorities  with  greater  accuracy  than  the  contract  documents 
because  it  was  developed  through  discussions  between  CAA  and  PSE  personnel  who  are 
directly  involved  in  the  GDAS  project  The  IWMP  is  a  "living"  document  that  is  updated 
periodically  in  response  to  changes  in  the  GDAS  development  schedule  or  changes  in  CAA 
preferences  for  allocation  of  resources  among  tasks. 

Information  from  the  model  developers  about  the  steps  to  be  performed  in  the  GDAS 
development  project  and  the  scheduled  dates  for  delivery  of  specific  items  such  as  the 
GDAS  prototype  software  established  much  of  the  schedule  for  the  IWMP.  Discussions 
with  the  GDAS  Contracting  Officer’s  Technical  Representative  (COTR)  and  other  CAA 
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personnel  involved  in  the  development  of  the  GDAS  yielded  preferred  government  priorities 
and  guided  the  allocation  of  PSE  resources  to  the  various  IVi&V  tasks. 

The  IWMP  developed  for  GDAS  Phase  II  incorporated  ongoing  tasking  and  activities 
begun  in  Phase  I,  but  was  revised  to  reflect  the  specific  tasks  laid  out  for  this  phase  of 
GDAS  rV&V  support.  This  IWMP  revision  was  delivered  to  CAA  on  6  July  1990.  No 
subsequent  updates  were  required  during  Phase  II  because  the  IV&V  management 
procedures  laid  out  in  the  initial  Phase  II  revision  were  appropriate  for  all  subsequent 
rV&V  activities.  Work  schedules  and  FV&V  products,  such  as  evaluations  of  GDAS 
development  products,  were  coordinated  through  meetings,  telephone  discussions,  and 
normal  correspondence,  including  faxes  and  letters. 

One  example  of  the  IV&V  management  procedures  used  in  Phase  n  is  the  coordination  of 
computer  work  sessions  to  evaluate  GDAS  software  products  delivered  by  the  model  devel¬ 
opers.  The  COTR  notifies  PSE  in  advance  of  the  upcoming  software  installation  date  and 
schedules  GDAS  computer  time  for  IV&V  work.  Before  the  scheduled  IV&V  computer 
session,  available  information  and/or  documentation  regarding  the  new  software  function¬ 
ality  is  passed  to  PSE.  This  information  is  used  to  plan  test  cases  for  the  evaluation  of 
specific  model  functions,  as  discussed  in  section  2.3.  Results  are  documented  during  the 
evaluation  and  are  normally  delivered  to  CAA  on  the  day  of  the  evaluation. 

2J  Independent  Verification  and  Validation  of  GDAS  Prototypes 

The  GDAS  development  schedule  evolved  from  a  traditional  "waterfall"  methodology  to 
several  iterations  of  prototype  models,  which  progressively  incorporate  more  of  the  features 
intended  for  the  final  GDAS  system.  IV&V  procedures  were  established  to  help  the 
government  assess  the  effectiveness  of  the  model  developer’s  quality  assurance  (QA)  and 
configuration  management  (CM)  activities  during  model  implementation  by  exercising  and 
evaluating  the  capabilities  of  each  prototype.  This  IV&V  approach  also  provides  the 
government  accurate  feedback  on  the  performance  of  GDAS  algorithms  early  in  the  model’s 
development  rather  than  waiting  until  the  formal  tests  for  model  acceptance.  PSE  activity 
on  this  task  began  in  Phase  I  and  has  continued  through  each  successive  prototype  delivered 
by  the  model  developers. 

The  exact  FV&V  procedures  used  at  a  particular  stage  in  the  evaluation  of  GDAS 
prototypes  are  determined  in  coordination  with  the  COTR.  This  has  been  an  iterative 
process  requiring  frequent  interaction  with  CAA  personnel.  For  the  evaluation  of  a 
particular  prototype  model,  it  is  necessary  to: 

o  Identify  the  features  of  the  prototype  that  are  newly  added  and  those  that 
were  corrected  from  an  earlier  version  to  determine  what  tests  should  be 
performed 
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o  Prioritize  the  list  of  features  and  tests  so  that  available  FV&V  resources  can 
be  allocated  to  the  most  significant  tests 

o  Schedule  a  series  of  model  runs  to  assure  the  availability  of  personnel, 
equipment,  and  data  for  specific  events 

0  Exercise  the  model  at  each  session  to  observe  and  assess  the  functions 
identified  for  examination  in  that  session 

o  Record  the  results  of  each  session  with  comments  on  the  functions  exercised 
and  any  model  deficiencies  or  discrepancies  noted 

o  Periodically  update  the  planned  run  schedule  to  provide  for  retesting  or 
additional  tests  based  on  the  results  of  previous  sessions 

o  Perform  literature  searches  and  hold  discussions  with  government  experts 
to  resolve  questions  or  issues  related  to  the  desired  performance  of  GDAS. 

All  of  these  procedures  may  be  executed  for  particular  prototype  features,  while  subsets  of 
these  procedures  are  selected  by  the  government  for  other  prototype  features  to  obtain  the 
greatest  possible  benefits  to  the  government  within  the  agreed-upon  level  of  effort  under  this 
contract.  Figure  2-1  illustrates  the  flow  of  information  regarding  GDAS  IV&V  planning  and 
results. 


COMMUNICATION  OF 
GDAS  IV&V  RESULTS 


IMOI 


Figure  2-1.  Communication  of  GDAS  IV&V  Results 


GDAS  IV&V  tests  are  planned  ahead  of  test  cases  such  as  those  in  appendix  A.  Each  test 
case  specifies  the  GDAS  function  to  be  evaluated,  the  input  data  tables  and  fields  to  be 
manipulated,  and  the  output  products  to  be  observed  (as  raw  output  data,  summary  output 
tables,  or  graphics).  Each  test  case  also  identifies  the  procedures  and  menu  selections 
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needed  to  accomplish  the  desired  evaluation.  As  much  of  this  information  as  possible  is 
developed  from  the  available  documentation  before  the  scheduled  IV&V  computer  session. 
On  the  day  of  the  computer  session,  the  planned  test  cases  are  briefly  reviewed  with  the 
COTR  before  proceeding  to  the  computer  room.  The  COTR  may  provide  guidance 
regarding  the  relative  priority  of  the  planned  tests  or  suggest  additional  tests  to  evaluate 
model  responses  encountered  by  CAA  personnel  during  initial  runs  of  the  newly  installed 
GDAS  capability. 

During  the  IV&V  computer  session,  the  test  steps  and  model  responses  are  recorded  as  they 
occur  on  PSE-developed  test  observation  forms,  which  are  presented  to  the  COTR  at  the 
conclusion  of  the  computer  session.  For  the  most  expedient  application  of  IV&V  results, 
completed  IV&V  test  observation  forms  are  normally  provided  directly  to  the  COTR  at  the 
end  of  the  computer  session  before  the  PSE  IV&V  team  leaves  the  CAA  offices.  The 
COTR  makes  desired  notations  in  a  space  on  the  form  for  this  purpose,  and  forwards  copies 
of  the  forms  to  the  model  developers  if  the  IV&V  results  indicate  a  need  for  software 
modifications. 

The  GDAS  Test  Observation  form  shown  in  figure  2-2  was  developed  by  PSE  as  a  vehicle 
for  effective  communication  among  PSE  IV&V  analysts,  CAA  personnel,  and  the  model 
developers  on  the  results  of  running  GDAS  prototypes.  At  least  one  form  is  completed  for 
each  trial  attempted  in  the  run  sessions  to  reflect  successful  completion  or  failure  of  the 
event.  The  forms  are  numbered  sequentially  and  a  copy  of  each  completed  form  is 
maintained  in  a  package  controlled  by  the  COTR  for  the  GDAS  development  project.  A 
block  at  the  bottom  of  the  form  marked  "For  CAA  Use"  provides  space  to  note  plans  for 
additional  work  related  to  each  event.  This  form  has  been  used  by  both  CAA  analysts  and 
the  model  developer,  and  their  suggestions  on  the  format  of  the  form  have  been 
incorporated. 

Phase  II  rV&V  tests  of  GDAS  prototypes  were  performed  in  December  1990  and  January 
1991.  These  tests  did  not  precisely  follow  the  normal  GDAS  FV&V  test  procedures 
described  above  because  the  capabilities  of  the  prototypes  were  not  described  in  advance. 
For  this  reason,  the  IV&V  computer  sessions  with  the  GDAS  prototypes  delivered  during 
this  time  frame  were  used  to  explore  the  capabilities  of  the  prototypes  and  experiment  with 
the  existing  capabilities  to  determine  their  functionality.  The  FV&V  computer  sessions 
resulted  in  27  GDAS  Test  Observations:  4  noted  existing  capabilities  and  23  noted 
discrepancies  in  the  GDAS  program  or  data.  The  test  observations  included  software 
problems  in  accessing  menu  selections  and  running  the  model  as  well  as  one  function  that, 
when  selected,  caused  a  complete  exit  from  GDAS.  Data  problems  included  empty  input 
tables,  incomplete  or  inconsistent  data  entries,  and  identic^  data  entries  for  lift  assets  or 
facilities  that  should  have  markedly  different  characteristics. 
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POTOMAC  SYSTEMS  ENGINEERING 
GDAS  Test  Observation 

Item  number: 

Date: 

Model  Component: 

_ Input  Data 

Summary  of  Observation: 


Complete  Description: 


For  CAA  Use 

Plan  Followup?  Review  Date:  Priority: 

Comment: 


PSEForm 


Analyst: 

Phone: 

Model  _ Results  _ Utility 


Figure  2-2.  GDAS  Test  Observation  Form 


2-5 


Besides  testing  GDAS  prototypes,  the  Phase  II  IV&V  work  under  this  task  included  support 
of  CAA  data  acquisition  and  preparation  efforts  for  anticipated  GDAS  testing.  One  effort 
involved  delineation  of  GDAS  airlift  data  requirements.  Another  involved  interpretation 
of  a  notional  logistics  deployment  scenario.In  conjunction  with  a  review  of  the  GDAS 
representation  of  airlift,  the  GDAS  COTR  requested  that  PSE  define  and  illustrate  the  air 
data  that  would  be  required  to  exercise  the  airlift  simulation  described  by  the  GDAS 
developers.  PSE  participated  in  the  GDAS  airlift  review,  analyzed  the  applicable  portions 
of  the  GDAS  SDS  and  Data  Dictionary,  and  developed  a  concise  description  of  the  airlift 
data  required  for  GDAS  and  how  it  would  be  used  in  the  simulation.  This  description  was 
then  used  by  the  GDAS  COTR  in  coordinating  a  request  to  Air  Force  sources  for  the 
required  airlift  data. 

CAA  also  acquired  from  the  U.S.  Transportation  Command  (USTRANSCOM)  a  set  of 
unclassified  time-phased  force  deployment  data  (TPFDD)  developed  for  a  USTRANSCOM 
training  plan.  The  data  files  and  instructions  provided  by  USTRANSCOM  were  incomplete, 
making  it  difficult  to  interpret  the  data  for  use  in  GDAS  data  tables.  PSE  analyzed  the 
instructions  and  data  files  provided  by  USTRANSCOM  to  determine  which  data  was 
appropriate  for  use  in  GDAS,  then  used  an  automated  data  base  tool  to  extract  the 
applicable  data.  Through  this  analysis,  PSE  was  able  to  provide  readable  data  tables 
containing  data  deciphered  from  the  USTRANSCOM  TPFDD  and  a  projection  of  the 
additional  data  (and  instructions)  that  would  be  necessary  to  use  the  USTRANSCOM 
deployment  scenario  in  GDAS  tests. 

2.4  Review  GDAS  Documentation 

PSE  analyzed  documents  generated  by  the  GDAS  model  developers  to  assess  whether  each 
document  was  technically  correct  and  consistent  with  other  related  GDAS  documents.  Each 
document  was  evaluated  for  its  compliance  with  the  format  and  content  specified  by  the 
government.  PSE  coordinated  with  the  COTR  to  obtain  the  following  documents  needed 
to  perform  the  document  reviews: 

o  Document  to  be  reviewed 

o  Applicable  development  contract  provisions  (e.g.,  SOW) 
o  Applicable  DoD  standards  and  associated  documentation 
o  Review  criteria  unique  to  the  document 
o  Previous  review  reports 

o  Correspondence  related  to  the  document’s  contents. 

Deviations,  errors,  and/or  ambiguities  in  format  and  content  were  reported  to  the 
government  with  recommended  corrective  actions.  The  effectiveness  of  PSE’s  thorough, 
constructive  IVi&V  reviews  was  formally  acknowledged  by  the  GDAS  COTR  and  by  the 
model  developers  (Stanley  Associates)  during  the  final  GDAS  System  Design  Briefing. 
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The  following  GDAS  documents  were  analyzed  by  PSE  during  IV&V  Phase  II: 

o  GDAS  System  Design  Specification  (Final,  July  1990) 

o  Related  letters,  papers,  and  memoranda 

o  GDAS  Functional  Description 

o  GDAS  Data  Dictionaries 

o  GDAS  Source  Code  (as  of  3  May  1990). 

Due  to  an  overlap  between  the  beginning  of  GDAS  IV&V  Phase  II  and  the  completion  of 
GDAS  development  Phase  I  (the  design  phase),  PSE  analyzed  and  provided  critical 
feedback  on  the  Final  GDAS  System  Design  Specification  (SDS)  during  IV&V  Phase  II. 
The  original  GDAS  SDS  was  analyzed  by  PSE  in  March  1991.  Because  of  feedback  from 
PSE  and  from  CAA  personnel  who  also  reviewed  the  original  SDS,  the  GDAS  developers 
published  a  revised  SDS  (Version  1.1).  Analysis  of  SDS  Version  1.1  by  PSE  and  CAA 
personnel  again  resulted  in  revision  of  the  SDS  by  the  GDAS  developers  to  produce  the 
final  SDS  version  that  was  delivered  at  a  GDAS  System  Design  Review  in  July  1990. 

PSE’s  analysis  of  the  final  GDAS  SDS  included  a  thorough  comparison  of  the  SDS  with  the 
GDAS  Functional  Description  (FD)  prepared  by  CAA  The  GDAS  COTR  provided,  as  a 
supplement  to  the  GDAS  FD,  a  file  of  letters,  papers,  and  memoranda  related  to  the  GDAS 
design  effort.  The  contents  of  this  file  reflected  agreements  and  open  issues  between  CAA 
and  the  model  developers  regarding  GDAS  design  features  that  supplanted  or  extended  the 
requirements  of  the  GDAS  FD.  These  supplemental  documents  were  used  as  references 
during  the  final  SDS  analysis  to  establish  a  comprehensive  perspective  for  assessment  of  the 
SDS. 

PSE’s  assessment  of  the  final  GDAS  SDS  included  general  observations  regarding  SDS 
compliance  with  the  applicable  requirements  and  standards  specified  by  CAA  and  a  list  of 
observations  regarding  significant  SDS  deficiencies.  The  observations  regarding  SDS 
deficiencies  were  keyed  to  specific  paragraphs  of  the  SDS  itself  and  included  discussions  of 
the  analysis  leading  PSE  to  the  assessment  of  a  deficiency  in  each  case.  Finally,  PSE’s 
review  of  the  final  GDAS  SDS  included  extracts  from  the  GDAS  FD,  highlighting 
requirements  that  were  not  satisfied  or  were  only  partially  satisfied  by  the  final  GDAS  SDS. 

A  GDAS  source  code  printout  provided  by  the  GDAS  COTR  was  reviewed  by  PSE  and 
used  with  the  GDAS  Data  Dictionary  to  clarify  the  design  of  several  GDAS  features  that 
were  not  adequately  described  in  the  GDAS  SDS.  The  source  code  itself  was  not  evaluated 
in  the  IV&V  context  as  a  deliverable  from  the  model  developers.  Documentation  of  the 
available  source  code  was  not  consistently  helpful  but  did  clarify  a  number  of  points  during 
the  IV&V  review  of  the  GDAS  SDS. 

Throughout  the  development  of  the  GDAS  PSE  has  provided  CAA  a  concise  IV&V 
assessment  of  each  document  reviewed.  Each  assessment  was  written  in  the  context  of 
previous  and  ongoing  GDAS  development  activities.  The  IV&V  comments  on  document 
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deficiencies  spelled  out  the  nature  of  the  problem,  why  it  was  considered  a  problem,  and 
the  possible  effect  of  the  problem  on  the  GDAS  development  project.  When  appropriate, 
the  IV&V  comments  also  recommended  an  approach  to  resolving  the  problem.  TTie  result 
of  this  approach  was  that  the  model  developer  used  many  of  PSE’s  IV&V  comments  as  the 
basis  for  improvements  in  the  GDAS  design  and  in  their  associated  documents. 

2.5  Support  and  Participate  in  GDAS  Program  Reviews 

PSE  supported  the  GDAS  development  project  by  participating  in  all  GDAS  system  reviews. 
During  formal  reviews,  PSE  analysts  abstained  from  discussion  as  instructed  by  the  COTR, 
and  provided  written  IV&V  feedback  on  significant  issues  that  arose  during  the  review. 

Within  five  working  days  after  participating  in  each  system  review,  PSE  provided  feedback 
to  CAA  on  discrepancies,  shortfalls,  or  issues  resulting  from  the  review  that  could  impact 
the  quality  of  the  GDAS  model  development.  Each  issue  that  PSE  raised  included  an 
explanation  of  why  it  was  considered  a  significant  issue  and  the  possible  impact  it  could  have 
on  the  GDAS  development  schedule  or  the  utility  of  the  final  GDAS  analysis  tool. 

Only  one  CAA  Agency  Review  Board  (ARB)  was  convened  for  a  GDAS  development 
review  during  GDAS  IV&V  Phase  II.  On  12  July  1990,  the  model  developer  briefed  the 
final  GDAS  System  Design  Specification.  The  PSE  feedback  on  this  review  highlighted  four 
issues:  the  GDAS  hardware  and  software  architecture,  complexity  of  the  transportation 
network,  planned  user  training  schedule,  and  interpretation  of  DoD  software  development 
standards. 

The  GDAS  COTR  informally  reviewed  the  GDAS  representation  of  airlift  at  the  model 
developer’s  offices  in  October  1990.  PSE  was  invited  to  participate  in  this  review  for  two 
reasons: 

o  To  assess  the  representation  of  airlift  being  implemented  in  GDAS 

o  To  gather  background  detail  for  a  capsulized  description  of  the  input  data 

required  for  the  GDAS  airlift  simulation. 

PSE’s  participation  in  this  informal  GDAS  development  review  was  more  extensive  than  in 
the  formal  reviews  previously  conducted  at  CAA.  We  supported  the  COTR  in  a  two-way 
question-and-answer  format  in  which  the  COTR  initiated  the  discussion  topics,  the  model 
developers  presented  the  current  design  and  status,  and  PSE  both  solicited  additional  detail 
and  provided  additional  information  regarding  the  real-world  airlift  system  that  the  GDAS 
developers  were  modeling.  PSE  feedback  on  this  model  review  included  the  usual  FV&V 
assessment  of  information  provided  by  the  developers  within  five  work  days  after  the  review. 

In  addition  to  the  IV&V  assessment,  PSE  also  matched  detailed  information  gained  from 
the  informal  GDAS  airlift  review  in  combination  with  the  GDAS  Data  Dictionary  to 
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develop  a  clear,  concise  description  of  GDAS  data  inputs  regarding  airlift.  We  included  a 
list  of  the  GDAS  data  base  tables  containing  data  regarding  airlift  and  described  how  the 
data  would  be  used  in  the  GDAS  airlift  simulation.  The  GDAS  COTR  used  PSE’s  descrip¬ 
tion  of  the  GDAS  representation  of  airlift  to  coordinate  with  Air  Force  data  sources  in 
requests  for  GDAS  airlift  data. 

2.6  Track  GDAS  Developmental  Activities 

The  primary  reason  for  tracking  GDAS  developmental  activities  was  to  facilitate  responsive 
planning  of  FV&V  activities.  PSE  also  helped  the  GDAS  COTR  maintain  focus  on  key 
action  items  and  issues  that  could  adversely  affect  the  GDAS  development  project.  The 
method  PSE  used  to  track  GDAS  development  activities  was  different  from  the  method  we 
originally  proposed  but  was  more  completely  integrated  with  other  aspects  of  the  FV&V 
process. 

The  major  differences  between  the  method  PSE  proposed  and  the  method  we  used  for  the 
GDAS  action  tracking  task  are  in  the  degree  of  automation  and  the  amount  of  analysis 
required.  PSE  initially  proposed  an  automated  action  tracking  data  base  linked  to  the 
GDAS  requirements  data  base.  Using  this  method,  each  item  designated  for  entry  into  the 
action  tracking  data  base  (e.g.,  meeting  minutes)  would  be  analyzed  to  identify  specific 
action  items.  Key  words  or  numeric  codes  showing  relationships  to  GDAS  requirements 
would  be  assigned  to  each  action  item.  The  coded  action  items  would  then  be  entered  into 
an  automated  data  base  and  customized  report  formats  would  be  established  to  retrieve 
items  periodically  or  on  request.  A  standard  monthly  report  could  show  all  open  action 
items  and  action  items  that  were  closed  during  the  previous  month.  Similarly,  the  GDAS 
COTR  could  request  a  report  showing  only  current  (or  prior)  action  items  related  to  specific 
requirements  (or  key  words).  A  time  lapse  between  the  beginning  of  the  GDAS  develop¬ 
ment  project  (May  1989)  and  the  beginning  of  GDAS  IV&V  work  (September  1989), 
combined  with  a  desire  for  fusion  of  GDAS  requirements  and  related  system  design  issues, 
led  to  a  CAA  decision  to  seek  an  alternate  method  for  GDAS  action  tracking  by  the  PSE 
rV&V  team. 

The  PSE  rV&V  team  leader  and  the  CAA  COTR  for  GDAS  development  held  meetings 
and  telephone  discussions  once  a  week  on  the  average  (sometimes  daily)  to  review  current 
GDAS  action  items  and  issues.  PSE  provided  written  reviews  or  working  papers  on  key 
factors  identified  in  these  discussions.  The  action  tracking  process  helped  PSE  prepare 
IV&V  products  focused  on  current  GDAS  design  issues  while  taking  account  of  prior  GDAS 
development  activities. 

One  example  of  the  FV&V  support  provided  by  PSE  as  a  result  of  the  action  tracking 
process  during  Phase  n  was  the  IV&V  input  to  CAA’s  mid-phase  change  in  the  GDAS  data 
base  management  system  (DBMS).  At  the  beginning  of  Phase  n,  the  GDAS  data  base 
development  plan  was  to  establish  the  GDAS  data  base  capability  using  the  Paradox  DBMS 
system  and  to  port  the  data  base  to  INGRES  during  the  final  stages  of  GDAS  development 
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and  integration.  As  the  implementation  of  GDAS  software  progressed,  the  capabilities  of 
Paradox  and  INGRES  were  reassessed  relative  to  GDAS  requirements.  PSE  became 
involved  in  this  discussion  during  its  early  stages  through  the  action  tracking  process. 
Participating  in  the  Paradox/INGRES  discussion  from  its  beginning,  the  PSE  FV&V  team 
was  able  to  provide  relevant  information  for  consideration  in  CAA’s  final  decision. 

PSE  tracked  GDAS  developmental  activities  manually  through  a  system  of  files  and 
calendars  maintained  mostly  at  PSE.  Updates  were  accomplished  through  a  flow  of 
telephone  calls,  meetings,  letters,  and  memoranda  between  PSE  and  the  CAA  COTR  for 
the  GDAS  development  project.  PSE  feedback  on  items  requiring  attention  was  provided 
to  the  COTR  in  telephone  calls,  meetings,  letters  containing  issues  from  program  reviews, 
PSE  reviews  of  GDAS  documentation,  and  GDAS  test  observations  resulting  from  prototype 
model  operations. 
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SECTION  3.  CONCLUSION 


PSE’s  GDAS  IV&V  Phase  II  support  during  the  implementation  of  the  GDAS  model  has 
contributed  to  the  model  design,  CAA’s  initial  data  collection  efforts,  and  the  overall  quality 
of  the  GDAS  software  suite.  As  the  GDAS  IV&V  agent,  PSE  continually  provided 
thorough,  objective,  and  constructive  evaluations  of  the  GDAS  design  features,  documenta¬ 
tion,  and  model  prototypes  delivered  to  CAA  by  the  model  developers.  PSE’s  participation 
in  GDAS  system  reviews  resulted  in  concise  and  timely  analytical  feedback  to  CAA  on 
issues  raised  during  each  review  that  could  adversely  impact  the  GDAS  development 
project.  PSE  also  contributed  FV&V  expertise  to  other  CAA  efforts  such  as  delineation  of 
GDAS  data  requirements  to  exercise  critical  model  features  and  analysis  of  data  obtained 
from  other  sources  to  determine  its  applicability  to  the  GDAS  database. 

PSE  activities  related  to  the  operation  and  evaluation  of  GDAS  model  prototypes  continued 
throughout  the  GDAS  Phase  II  IV&V  contract  period.  One  important  aspect  of  software 
evaluation  is  the  preliminary  planning  and  coordination  of  tests  that  will  be  performed.  The 
preliminary  steps  include  reviewing  and  analyzing  available  documentation,  analyzing 
previous  test  results,  designing  and  preparing  test  data  sets,  and  scripting  test  procedures. 
PSE’s  procedures  for  IV&V  test  planning  and  coordination  have  produced  efficient  and 
accurate  assessments  of  the  software  delivered  by  the  GDAS  developers.  In  addition  to  the 
software  tests  performed  during  the  GDAS  IV&V  Phase  II  contract  period,  some 
preliminary  planning  has  been  done  for  tests  of  software  that  is  yet  to  be  delivered  by  the 
GDAS  developers.  The  test  cases  themselves  are  not  a  required  deliverable  of  GDAS 
IV&V  Phase  11  but  are  included  in  appendix  A  for  informational  purposes.  Some  of  the  test 
cases  plaimed  for  upcoming  GDAS  prototypes  are  incomplete  because  the  features, 
functionality,  and  operating  procedures  for  the  prototypes  are  not  clearly  known  at  this  time. 
All  of  these  test  cases  must  be  checked  against  the  final  data  dictionary  and  operational 
procedures  of  the  GDAS  version  with  which  they  are  used. 

A  number  of  additional  steps  must  be  taken  to  maintain  and  build  on  the  contributions  that 
the  PSE  rV&V  team  has  made  to  the  GDAS  development  project.  According  to  the  current 
GDAS  development  schedule,  two  GDAS  prototypes  are  planned  for  delivery  to  CAA 
before  the  final  GDAS  system  is  delivered.  Each  prototype  should  be  evaluated  in  the  same 
manner  as  the  previous  prototypes.  Each  should  be  checked  to  determine  whether  it 
includes  corrections  to  problems  discovered  in  earlier  versions,  then  to  determine  the 
functionality  of  added  features.  The  IV&V  test  cases  in  appendix  A  should  be  completed 
and  added  to  for  evaluation  of  the  GDAS  prototypes  and  for  acceptance  testing  of  the  final 
GDAS  system.  Data  must  be  collected  and  prepared  for  these  tests  and  for  eventual 
application  of  the  model  in  deployment  studies.  Finally,  before  the  GDAS  system  enters 
the  "operations  and  maintenance"  phase  of  its  life  cycle,  a  pilot  study  should  be  conducted 
with  a  scenario  representative  of  the  studies  in  which  the  model  is  expected  to  be  used. 


3-1 


APPENDIX  A 

POTENTIAL  GDAS  IV&V  TEST  CASES 


A-1 


APPENDIX  A 


POTENTIAL  GDAS  IV&V  TEST  CASES 


The  documents  in  appendix  A  represent  work  in  progress  on  potential  test  cases  for  GDAS 
prototypes  and  for  the  final  GDAS  model.  This  work  was  accomplished  as  a  foundation  for 
preparing  an  IV&V  Test  Plan,  which  would  include  additional  details  of  data  and 
procedures  based  on  documents  not  yet  delivered  by  the  GDAS  developers.  The  anticipated 
documentation  includes  the  Hnal  GDAS  Data  Dictionary,  a  User’s  Manual,  and  Detailed 
Algorithm  Specifications.  It  is  expected  that  these  documents  will  clarify  the  relationships 
between  the  GDAS  simulation  inputs,  system  parameters,  and  output  data  that  is  not 
available  in  the  System  Design  Specification  (SDS)  or  in  the  available  version  of  the  GDAS 
Data  Dictionary  (dated  19  December  1990).  The  potential  test  cases  included  in  this 
appendix  were  developed  during  GDAS  Phase  II  IV&V  when  schedule  delays  by  the  model 
developer  created  slack  time  in  the  IV&V  schedule. 

Three  lists  of  candidate  tests  were  prepared  at  different  times  and  from  different  sources. 
The  lists  were  developed  from  the  GDAS  Functional  Description  (FD)  and  SDS,  and  from 
correspondence  and  meeting  minutes  regarding  GDAS  design  features.  It  is  anticipated  that 
as  the  test  cases  are  updated  from  documentation  of  pending  GDAS  prototypes  and  of  the 
final  GDAS  implementation,  the  additional  detail  available  will  spawn  related  tests.  As  test 
cases  were  prepared,  the  analysis  of  GDAS  requirements  associated  with  each  candidate  test 
revealed  that  some  items  seemed  to  duplicate  items  on  another  list.  Related  items  on  the 
candidate  test  lists  will  be  compared  with  the  Hnal  GDAS  documentation  to  determine 
whether  nuances  of  function  not  expressed  in  the  SDS  or  the  available  data  dictionary  will 
indicate  that  the  candidate  test  issues  are  not  identical. 

For  convenience  in  developing  the  tests,  each  test  case  is  assigned  a  number  corresponding 
to  its  position  on  a  list  of  candidate  tests.  The  number  assigned  to  each  test  case  has  two 
parts,  the  Hrst  part  indicating  the  list  it  came  from  and  the  second  part  indicating  its  position 
in  the  cumulative  sequence  of  all  cases  in  the  three  lists.  Test  case  2-27  is  from  the  second 
list  of  candidate  tests,  and  is  the  twenty-seventh  candidate  test  in  the  cumulative  list  of 
candidate  tests.  As  the  GDAS  development  process  draws  to  a  close,  the  completed  test 
cases  will  be  recategorized  by  GDAS  subsystem  and  function,  and  by  test  priority. 

Finally,  the  requirement  statements  have  been  modified  from  their  initial  contents  in  most 
of  these  test  cases.  The  GDAS  FD  was  originally  the  primary  source  for  requirements  and 
evaluation  criteria  in  these  test  cases.  The  GDAS  SDS  was  a  secondary  source,  to  be  used 
for  test  requirements  not  based  in  the  GDAS  FD.  Due  to  recent  developments,  CAA  asked 
that  PSE  base  all  GDAS  IV&V  test  cases  on  requirements  expressed  in  the  GDAS  SDS. 
This  revision  has  been  performed  to  the  extent  possible,  as  in^cated  in  the  test  cases. 


GDAS  IV&V  TEST  CASE  DESCRIPTION 


rV&V  ISSUE:  A  brief  statement  or  phrase  indicating  the  nature  of  the  test  to  be 
performed. 

GDAS  SUBSYSTEM:  Name  of  the  GDAS  subsystem  to  be  evaluated  in  this  test  (data  base, 
presentation  graphics,  transportation  graphics,  movement  requirement  generation,  or 
transportation  model). 

REQUIREMENT  SOURCE:  Name  or  description  of  the  source  for  the  stated  requirement 
upon  which  the  test  is  based. 

REQUIREMENT  STATEMENT:  The  GDAS  system  requirement  or  design  specification 
describing  the  capability  to  be  tested.  Test  requirements  may  also  be  generated  fi’om  the 
contract  Statement  of  Work,  related  correspondence,  or  other  sources  describing  intended 
GDAS  capabilities  (to  be  coordinated  with  the  GDAS  COTR). 

TEST  OBJECTIVE:  A  statement  of  what  is  to  be  determined  by  the  test  to  be  performed. 

TEST  PROCEDURES:  A  general  description  of  steps  to  be  performed  for  the  test.  This 
may  include  test  setup,  special  input  data  requirements,  and  requirements  for  hardware  or 
software  that  is  not  part  of  the  GDAS  architecture.  Additional  information  sources  (data 
sources,  instruction  manuals)  may  be  included  by  reference. 

DATA  COLLECTION  REQUIREMENTS:  A  description  or  list  of  data  that  will  provide  a 
basis  for  assessment  of  test  results.  This  data  will  normally  be  GDAS  system  output  or 
observations  of  system  performance  collected  during  the  test. 

EVALUATION  CRITERIA:  A  description  or  list  of  criteria  against  which  the  test  results 
will  be  assessed.  Criteria  for  these  tests  will  emphasize  the  concerns  of  greatest  interest  for 
the  current  phase  of  GDAS  development. 
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IV&V  ISSUE:  Identify  anomalies  in  cargo  travel  itineraries. 

GDAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GDAS  COTR. 

REQUIREMENT  STATEMENT:  Be  able  to  trace  cargo  delay  to  lack  of  availability  of 
transportation  assets  transportation  assets  or  to  port  congestion.  Relate  such  results  to  the 
trouble  report. 

TEST  OBJECTIVE:  Confirm  scheduler  problems  identified  In  previous  runs  and  attempt  to 
identify  the  cause.  Two  unusual  cases  of  cargo  lateness  were  reported: 

o  Late  cargo  was  loaded  on  a  ship  that  sat  in  port  for  10  days  while  similar  ship/cargo 
combinations  sailed  to  destination. 

o  Cargo  destined  for  the  Persian  Gulf  was  loaded  on  a  ship  that  made  several  round  trips 
between  CONUS  and  NATO  before  going  to  Persian  Gulf. 

TEST  PROCEDURES:  Run  queries  on  GDAS  output  data  to: 

o  Find  the  cargo  delivered  longest  after  its  RDD 
o  Obtain  the  itinerary  of  the  shlp(s)  or  aircraft  that  transported  the  cargo 
o  Determine  whether  the  cargo  was  late  loading  or  delayed  en-route 
o  Identify  delays  contributing  to  the  cargo’s  lateness. 

NOTE:  The  GDAS  rejection  report  (trouble  report?)  only  Identifies  reason(s)  for  cargo  not 
being  scheduled  within  a  user-specified  time  window  of  its  TLD. 

DATA  COLLECTION  REQUIREMENTS:  Data  to  be  collected  in  this  test  Includes  the  results  of 
queries  run  during  the  test  and  observations  regarding  cargo  delays  indicated  by  the  results. 
Any  entries  in  the  trouble  report  regarding  the  Identified  cargo  will  be  extracted  and  the  user- 
specified  time  window  will  be  recorded. 

EVALUATION  CRITERIA:  Two  criteria  will  be  used  In  this  test: 

o  It  should  be  possible  to  identify  the  reasons  for  cargo  lateness  using  standard  GDAS 
queries. 

o  The  trouble  report  should  list  the  reasons  for  not  loading  cargo  within  the  user-specified 
window. 
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GDAS  IV&V  TEST  CASE  #  1-2 


IV&V  ISSUE:  Aerial  refueling  on  airlift  missions. 

GDAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GDAS  SDS  para  5.4.1. 

REQUIREMENT  STATEMENT:  In  GDAS,  the  transportation  network  is  basically  defined  by 
nodes  and  links.  Typical  nodes  may  represent  origins,  destinations,  airports,  seaports,  truck  or 
rail  terminals,  airdrop  nodes,  air  refueling  points,  etc. 

TEST  OBJECTIVE:  Verify  aerial  refueling  capability  for  GDAS  airlift  missions.  It  should  be 
possible  to  reduce  transit  time  for  airlifted  cargo  by  substituting  aerial  refueling  for  intermediate 
landings. 

TEST  PROCEDURES:  Choose  a  GDAS  run  in  which  airlift  missions  stop  for  fuel  only  (e.g., 
CONUS  to  Persian  Gulf).  Create  an  aerial  refueling  node  bisecting  a  long  link  such  as  the 
transatlantic  leg.  Run  the  model  again  and  check  the  output  for  aircraft  visiting  the  aerial 
refueling  node. 

DATA  COLLECTION  REQUIREMENTS:  Identify  the  cargos  on  aircraft  using  the  aerial 
refueling  node  and  their  transit  time  from  POE  to  POD.  Compare  transit  times  for  the  same 
cargos  (if  airlifted)  in  the  base  run. 

NOTE:  Check  whether  this  procedure  would  be  simplified  by  using  a  "special  mission." 


EVALUATION  CRITERIA:  Aerial  refueling  nodes  should  be  used  In  lieu  of  landing  for  fuel  only. 
Airlift  transit  times  (POE  -  POO)  should  decrease  when  aerial  refueling  is  used. 
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GDAS  IV&V  TEST  CASE  #  1-3 


IV&V  ISSUE:  Effect  of  canal  closure  on  ship  routing. 

GDAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GOAS  SOS  para  5.1. 

REQUIREMENT  STATEMENT:  In  GDAS,  the  scheduling  decisions  and  simulations  are 
performed  each  day  within  an  iterative  process  that  is  patterned  after  real-world  transportation 
schedulers.  Major  steps  in  the  daily  process  include  replanning  and/or  re-scheduling  to  take 
into  account  "surprise*  time  variations  (e.g.,  canal  closures)  not  foreseen  during  planning  and 
scheduling. 

TEST  OBJECTIVE:  Confirm  that  GDAS  will  perform  an  appropriate  ship  diversion  if  its 
destination  port  (or  canal  passage)  closes  while  the  ship  is  en-route. 

TEST  PROCEDURES:  Choose  a  run  where  ships  use  a  canal  (e.g.,  Suez  or  Panama).  Enter 
"timevarying"  data  to  close  a  selected  canal  one  day  before  ships  are  scheduled  to  transit  the 
canal.  Rerun  the  scenario  and  compare  the  itineraries  of  ships  that  used  the  canal  in  the  base 
run. 


DATA  COLLECTION  REQUIREMENTS:  Identify  and  obtain  Itineraries  of  ships  transiting 
canals  in  the  base  run.  Obtain  itineraries  of  the  same  ships  in  the  excursion. 

EVALUATION  CRITERIA:  Ships  should  not  transit  the  canal  during  the  closed  period. 
Itineraries  of  identified  ships  should  be  the  same  in  the  excursion  as  in  the  base  run  until  the 
stop  just  before  using  the  canal  (unless  mission  is  planned  after  the  canal  closes).  Itinerary  In 
the  excursion  should  provide  a  feasible  route  avoiding  the  canal. 
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GOAS  IV&V  TEST  CASE  #  1-4 


L, 
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IV&V  ISSUE:  Effect  of  airport  closure  on  airlift  routing. 


GOAS  SUBSYSTEM:  Transportation  Model. 


REQUIREMENT  SOURCE:  GOAS  SOS  para  5.9. 


REQUIREMENT  STATEMENT:  To  determine  the  trade-off  between  payloads  and  refueling, 
GOAS  uses  a  forward-reaching  dynamic  programming  method  as  illustrated  in  figure  5-8.  The 
objective  is  to  achieve  the  maximum  average  tons  per  day  throughput  and  to  identify  standard 
routes  depending  on  the  aircraft  type. 


TEST  OBJECTIVE:  Confirm  that  GOAS  will  perform  feasible  lift  vehicle  diversion  if  a  port  Is 
closed  while  a  mission  is  en-route.  The  test  procedure  is  described  for  aircraft  and  airports;  a 
similar  procedure  will  be  used  for  ships  and  seaports. 

TEST  PROCEOURES:  Choose  a  busy  airport  from  an  existing  run.  Enter  ‘timevarying*  data  to 
close  the  selected  airport  during  a  period  of  high  activity.  Rerun  the  scenario  and  compare  the 
itineraries  of  aircraft  that  used  the  airport  in  the  base  run. 

OATA  COLLECTION  REQUIREMENTS:  Identify  and  obtain  itineraries  of  aircraft  using  the 
selected  airport  in  the  base  run.  Obtain  itineraries  of  the  same  aircraft  in  the  excursion. 


EVALUATION  CRITERIA:  Aircraft  should  not  use  the  airport  during  the  dosed  period. 
Itineraries  of  Identified  aircraft  should  be  the  same  in  the  excursion  as  in  the  base  run  until  the 
stop  just  before  the  selected  airport  (unless  mission  is  planned  after  the  airport  doses). 
Itinerary  in  the  excursion  should  provide  a  feasible  route  avoiding  the  closed  airport.  Aircraft 
and  cargos  at  the  airport  when  it  closes  should  not  be  processed  during  the  dosed  period. 


IV&V  ISSUE:  Dynamic  selection  of  convoy  assembly  locations. 

GDAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GDAS  SDS  para  5.10. 

REQUIREMENT  STATEMENT:  If  a  movement  requirement  has  a  destination  in  a  theater  for 
which  convoying  operations  have  begun,  and  if  a  given  ship  must  be  convoyed  based  on  the 
convoy  speed  criterion,  then  a  separate  calculation  is  performed  to  identify  the  nearest  convoy 
assembly  node  and  disassembly  node  based  on  great  circle  distances. 

TEST  OBJECTIVE:  Confirm  that  GDAS  selects  the  nearest  convoy  assembly  node  to  the  POE 
for  ships  going  to  a  particular  theater.  Also  determine  whether  the  proximity  of  a  disassembly 
node  to  the  POD  is  a  planning  factor.  (NOTE:  Fields  in  table  CONVOY  im^y  a  single 
assembly  node  and  a  single  disassembly  node  for  each  convoy  route.  Which  determines  route 
selection?) 

TEST  PROCEDURES:  Select  or  create  a  NATO  deployment  scenario  with  at  least  two  active 
convoy  routes  from  CONUS  to  NATO.  Identify  ships  that  use  the  convoy  routes  and  determine 
the  distance  of  their  last  POE  stop  from  each  availaUe  convoy  assembly  point.  Also  determine 
distance  to  each  ship's  first  POD  stop  from  each  available  convoy  disassembly  point. 

DATA  COLLECTION  REQUIREMENTS:  Get  itineraries  of  ships  using  convoy  routes  and 
locations  of  available  convoy  assembly/disassembly  nodes.  Should  use  the  same  formula 
used  in  GDAS  to  compute  distances,  ^he  Transportation  Graphics  subsystem  may  be  useful 
in  this  test.) 

EVALUATION  CRITERIA:  Ships  using  convoy  routes  should  proceed  from  their  last  CONUS 
POE  stop  to  the  nearest  convoy  assembly  node. 
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GDAS  IV&V  TEST  CASE  #  1-S 


IV&V  ISSUE:  Cargo  marry-up/assembly  in  a  theater. 

GDAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GDAS  SOS  para  5.2. 

REQUIREMENT  STATEMENT:  The  GDAS  model  design  explicitly  accounts  for  the 
coordination  of  multiple,  interdependent  movements  which  are  characteristic  of  DoD  intermodal 
transportation,  including  cargos  which  are  related  by  precedence  sequencing  (e.g.,  a 
multimodal  staged  movement  in  which  an  airlift  leg  depends  on  a  prior  sealift  leg),  or  assembly 
dependency  (e.g.,  multiple  air/sea  or  POMCUS  movements  which  must  marry  up  at  a 
marshalling  or  staging  location  before  moving  forward),  or  balanced  force  links  (e.g., 
CS/CSS/supply  movements  which  are  assigned  to  support  a  combat  unit). 

TEST  OBJECTIVE:  Confirm  that  GDAS  can  represent  deployment  situations  in  which 
requirements  must  be  matched  after  POO  arrival  (e.g.,  people  and  equipment)  befora 
proceeding  to  final  destination. 

TEST  PROCEDURES:  Enter  or  check  data  in  tables  REQUIRE,  REQMATCH,  REQNODE,  and 
THTRREQ  as  necessary  to  identify  the  movement  requirements  that  must  be  assembled  in 
theater.  Run  the  model  and  check  cargo  itineraries  to  establish  that  all  requirements  were  at 
the  assembly  node  for  the  prescribed  time  period  before  any  moved  past  the  assembly  node. 

DATA  COLLECTION  REQUIREMENTS:  Requirements  and  theater  data  showing  which 
requirements  must  be  matched  and  where  as  well  as  the  time  required  for  marry-up.  Also  need 
cargo  itineraries. 


EVALUATION  CRITERIA:  Ail  matched  requirements  should  arrive  at  the  assembly  node.  The 
specified  minimum  time  period  should  pass  before  the  last  matched  cargo  arrives  before  any  of 
the  matched  cargo  departs  the  assembly  node. 
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IV&V  ISSUE:  Discrete-event  attrition  of  lift  vehicles  and  cargo. 


GOAS  SUBSYSTEM:  Transportation  Model. 
REQUIREMENT  SOURCE:  GOAS  SOS  para  5.14. 


REQUIREMENT  STATEMENT:  Attrition  submodels  at  the  nodes  are  expressed  as  discrete 
probabilities.  The  discrete  probability  is  applied  to  vehicles  upon  port  departure  after  any 
cargo  has  been  loaded  or  unloaded. 

TEST  OBJECTIVE:  Confirm  that  the  optional  discrete-event  attrition  (upon  port  departure)  in 
GDAS  operates  as  planned.  The  cargo  actually  on  board  an  attrited  vehicle  should  also  be 
attrited. 


TEST  PROCEDURES:  Query  the  output  from  one  GDAS  run  where  discrete-event  attrition  is 
enabled.  The  following  steps  should  provide  the  necessary  information: 

o  Identify  all  attrited  vehicles 

o  Identify  all  cargo  loaded  on  each  vehicle  at  time  of  loss 
o  Confirm  that  the  identified  cargo  is  attrited  before  reaching  POO 
o  Confirm  that  no  other  cargo  is  attrited  before  reaching  POD. 

DATA  COLLECTION  REQUIREMENTS:  List  of  attrited  vehicles  and  attrited  cargo.  Itineraries 
for  attrited  vehicles,  including  cargo  loaded  and  unloaded  at  each  stop. 


EVALUATION  CRITERIA:  Three  criteria  will  be  used  in  this  test: 

o  The  cargo  loaded  on  the  attrited  lift  vehicles  at  the  time  of  attrition  should  not  arrive  at 
POD. 

o  The  quantity  of  cargo  attrited  should  match  the  quantity  of  cargo  loaded  on  the  lift  vessel 
at  the  time  of  its  loss. 

o  No  other  cargo  should  be  removed  from  the  simulation  unless  it  Is  attrited  at  a  port. 
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IV&V  ISSUE:  Exclusion  of  fleets  from  specific  theaters. 

GDAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GDAS  SDS  para  5.4.2. 

REQUIREMENT  STATEMENT:  Facilities  can  be  constrained  as  to  whether  refueling  is 
permitted  and  which  types  of  vehicles  can  be  handled  (e.g.,  C-I7s  may  be  unable  to  land  at 
certain  airports,  or  NATO  fleets  may  be  excluded  from  Korean  seaports,  or  military  aircraft  only 
are  permitted  at  airdrop  facilities  which  have  reduced  unload  rates). 

TEST  OBJECTIVE:  Confirm  that  GDAS  has  the  capability  to  dedicate  a  'ileef  of  ships  to  one 
theater  and  to  exclude  that  fleet  from  another  theater. 


TEST  PROCEDURES:  Identify  (from  an  existing  run)  a  class  of  ships  that  is  used  in  missions 
to  several  theaters.  Designate  this  class  of  ships  as  a  fleet  In  tables  SHIP  and  SHIPFLT.  Use 
table  EXCLUDE  to  exclude  this  fleet  from  a  theater  (or  node/facility)  that  was  used  by  the 
designated  class  of  ships  In  the  base  run.  Run  the  excursion  and  check  whether  ships  in  the 
designated  fleet  avoid  the  excluded  theater  (or  node/faclllty). 

DATA  COLLECTION  REQUIREMENTS:  Itineraries  of  ships  in  the  designated  fleet. 

EVALUATION  CRITERIA:  Ships  excluded  from  a  theater  (or  node/facility)  should  not  be  used 
to  transport  cargo  to  or  from  that  facility.  (Question:  What  happens  if  you  exclude  a  fleet  from 
CONUS?) 


IV&V  ISSUE:  Dynamic  selection  of  cargo  iift  mode. 

GDAS  SUBSYSTEM:  Transportation  Modei. 

REQUIREMENT  SOURCE:  GDAS  SDS  para  5.1. 

REQUIREMENT  STATEMENT:  For  scheduling,  the  model  uses  mathematical  optimization 
algorithms  and  heuristic  scheduling  techniques  to  make  decisions  such  as  mode  selection 
between  airlift,  sealift,  or  other  transportation  modes. 

TEST  OBJECTIVE:  Confirm  that  the  GDAS  scheduler  will  automatically  select  an  appropriate 
transportation  mode  when  a  movement  requirement  does  not  specify  a  transportation  mode. 

TEST  PROCEDURES:  Select  or  create  a  scenario  with  numerous  air  transportable  cargos 
(e.g.,  bulk)  that  do  not  have  a  designated  transport  mode  but  are  destined  to  the  same  theater. 
Identify  a  group  of  cargos  for  the  test  and  divide  them  in  half.  Set  dates  for  one  half  so  airlift  is 
the  only  possible  mode  to  meet  the  RDD  and  set  dates  for  the  other  half  to  allow  timely 
delivery  by  sealift.  (Available  dates  in  table  REQUIRE  are  RLD,  EDD,  and  ROD.) 

NOTE:  Selected  cargos  should  not  be  linked  to  any  others.  It  may  be  best  to  use  resupply 
cargos. 

DATA  COLLECTION  REQUIREMENTS:  Obtain  travel  mode  and  load/unload  dates  for 
selected  requirements.  Use  ad  hoc  queries  to  research  anomalies.  May  need  to  determine 
cargo  priority  or  delivery  benefit  relative  to  similar  cargo. 

EVALUATION  CRITERIA:  Cargo  with  short  movement  windows  should  primarily  use  airlift 
mode.  Cargos  with  long  movement  windows  should  primarily  use  sealift  mode. 


IV&V  ISSUE:  Dynamic  selection  of  POE  and  POO. 


GDAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GDAS  SOS  para  5.6. 

REQUIREMENT  STATEMENT:  The  planning  process  routes  a  movement  requirement  from  an 
assigned  starting  node  (either  the  initial  origin  or  an  intermediate  origin  which  represents  the 
end  node  of  a  previously  scheduled  cargo)  through  the  transportation  network  to  its  final 
destination,  possibly  through  several  modes  of  transport.  The  planning  methodology  uses  a 
node-oriented  shortest  path  type  algorithm  as  an  outer  framework,  but  actually  uses  forward- 
reaching  dynamic  programming  to  evaluate  alternate  states  at  each  node  since  multiple  penalty 
criteria  must  be  evaluated  as  well  as  linking  dependencies  to  other  scheduled  cargo. 

TEST  QBJECTIVE:  Confirm  that  for  a  given  movement  requirement  GDAS  will  select  the 
nearest  POE  to  cargo  origin  and  the  nearest  POD  to  cargo  destination. 

TEST  PROCEDURES:  Select  movement  requirements  destined  to  each  theater  played  in  a 
scenario.  Find  each  POE  and  POD  used  to  move  the  selected  requirements.  Check  an  area 
around  each  cargo  origin  to  determine  whether  any  POE  is  closer  and  check  an  area  around 
each  cargo  destination  whether  any  POO  Is  closer  than  the  ones  used  in  the  simulation.  If  so, 
check  ship  availability,  total  cargo  throughput,  and  cargo  priorities  at  closest  ports  to  determine 
why  they  were  not  used. 

NOTE:  Transportation  graphics  may  help  with  this  test  if  available. 

DATA  COLLECTION  REQUIREMENTS:  The  following  data  will  be  needed: 

o  Selected  cargo  requirements  by  theater. 

o  Origin  and  destination  for  each  cargo. 

o  Distances  from  origin  to  POEs  and  from  PODs  to  destination. 

EVALUATION  CRITERIA:  Cargo  should  transit  the  POE  nearest  to  its  origin  and  the  POO 
nearest  to  its  destination. 
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IV&V  ISSUE:  Intermediate  staging  operations. 


GOAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GOAS  SOS  para  5.2. 

REQUIREMENT  STATEMENT:  The  GOAS  model  design  explicitly  accounts  for  the 
coordination  of  multiple,  interdependent  movements  which  are  characteristic  of  OoO  intermodal 
transportation,  including  cargos  which  are  related  by  precedence  sequencing  (e.g.,  a 
multimodal  staged  movement  in  which  an  airlift  leg  depends  on  a  prior  sealift  leg),  or  assembly 
dependency  (e.g.,  multiple  air/sea  or  POMCUS  movements  which  must  marry  up  at  a 
marshalling  or  staging  location  before  moving  forward),  or  balanced  force  links  (e.g., 
CS/CSS/supply  movements  which  are  assigned  to  support  a  combat  unit). 

TEST  OBJECTIVE:  Confirm  that  GDAS  has  the  capabiiity  to  use  intermediate  staging 
locations  where  cargo  changes  vehicles  or  modes  of  transport 


TEST  PROCEDURES:  Select  or  create  at  least  two  movement  requirements  with  staging.  Use 
tables  REQNODE  and  STAGE  to  enter  EAO,  LAD,  and  delay  days  at  the  stage  node  and  other 
pertinent  staging  information.  Run  model  and  check  itineraries  of  the  selected  requirements  for 
compliance  with  staging  inputs. 

DATA  COLLECTION  REQUIREMENTS:  itineraries  for  selected  requirements. 

EVALUATION  CRITERIA:  GDAS  scheduler  should  stage  the  movement  requirements 
according  to  the  input  times. 
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IV&V  ISSUE:  Representation  of  mechanical  vehicle  failure. 

GDAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GOAS  COTR. 

REQUIREMENT  STATEMENT:  COULD  NOT  FIND  1  HIS  REQUIREMENT  IN  FD  OR  SDS. 

TEST  OBJECTIVE:  Confirm  that  GDAS  transportation  vehicles  experience  delays  due  to 
mechanical  failures  requiring  en-route  maintenance  or  return  to  port. 

TEST  PROCEDURES:  To  be  determined.  It  appears  that  only  attrition  or  combat  damage  can 
affect  a  lift  vehicle  during  a  simulation.  (The  definition  of  the  *Do  Attrition?*  field  In  table 
PARAM  indicates  it  Is  used  for  attrition  or  breakdown,  but  no  other  reference  to  breakdown 
could  be  found.) 

DATA  COLLECTION  REQUIREMENTS:  To  be  determined. 

EVALUATION  CRITERIA:  To  be  determined. 


IV&V  ISSUE:  Balanced  forces  linking  capability. 


GOAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GDAS  SOS  para  5.18. 

REQUIREMENT  STATEMENT:  The  balanced  forces  concept  occurs  in  GDAS  to  ensure  that 
combat  support  units  follow  associated  combat  units  in  a  timely  fashion. 

TEST  OBJECTIVE:  Confirm  that  GOAS  has  the  capability  to  schedule  cargos  according  to 
input  balanced  force  links. 


TEST  PROCEDURES:  Select  or  create  a  set  of  related  combat  and  combat  support  unit 
requirements.  Enter  the  predecessor/successor  requirement  IDs  and  desired  lag  time  in  table 
REQLAG.  Run  the  model  and  check  itineraries  of  the  selected  requirements  for  compliance 
with  the  input  links. 

DATA  COLLECTION  REQUIREMENTS:  Identify  related  combat  and  combat  support 
requirements.  Obtain  movement  Itineraries  for  the  selected  requirements. 


EVALUATION  CRITERIA:  Two  criteria  will  be  used  in  this  test: 

o  Predecessor  cargos  should  arrive  before  successor  cargos, 
o  Successor  cargos  should  lag  by  the  input  lag  days. 


A-16 


IV&V  ISSUE:  Capability  for  CRD  or  SRO  to  override  ROD. 

GOAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GDAS  SDS  para  2.2. 

REQUIREMENT  STATEMENT:  The  analyst  will  have  the  option  of  altering  scheduling  priorities 
by  modifying  the  penalties  assigned  to  the  control  variables  associated  with  each  goal,  or  by 
modifying  the  simulation  ROD. 

TEST  OBJECTIVE:  To  be  determined.  CRD  stands  for  CINC’s  RDD  (table  UNIT),  defined  as 
the  CINC’s  original  required  delivery  date  relative  to  M-day.  The  RDD  In  table  REQUIRE 
apparently  drives  the  simulation,  but  the  connection  between  the  two  dates  is  not  defined. 

Need  a  definition  for  SRO  (could  be  Simulation  RDD,  ref  SDS  page  2-4). 

TEST  PROCEDURES:  To  be  determined.  The  SOS  does  not  describe  how  the  CRD  or  SRD 
can  be  substituted  for  the  Requirement  ROD  during  a  run.  The  GDAS  User’s  Manual,  when 
published,  should  provide  the  necessary  procedures.  If  this  test  must  be  performed  before  the 
User’s  Manual  Is  available,  the  procedure  should  be  requested  from  the  model  developers. 

DATA  COLLECTION  REQUIREMEN’TS:  To  be  determined.  The  basic  set  of  data  required  for 
this  test  will  include  the  Requirement  ROD  and  the  CINC’s  ROD  for  a  set  of  data  as  well  as 
output  regarding  the  actual  cargo  delivery  dates. 

EVALUATION  CRITERIA:  Designated  cargo  requirements  should  be  delivered  on  or  before 
the  CINC’s  ROD.  Qosure  and  lateness  calculations  should  be  relative  to  the  CINC’s  RDD. 


A-17 


IV&V  ISSUE:  Analyst  control  of  cargo  movement  priorities. 


GDAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GDAS  SDS  para  5. IS. 

REQUIREMENT  STATEMENT:  The  major  criteria  for  sorting  cargos  is  the  Target  Lift  Date 
(TLD)  calculated  during  the  planning.  Among  all  cargos  with  the  same  TLD,  the  analyst  can  set 
the  movement  priority  to  ensure  the  most  important  movements  have  the  best  chance  of 
obtaining  transportation  resources. 


TEST  OBJECTIVE:  Confirm  that  GDAS  schedules  cargos  according  to  input  movement 
priority. 


TEST  PROCEDURES:  Identify  or  create  a  set  of  movement  requirements  (at  least  three)  going 
from  the  same  origin  to  the  same  destination  with  the  same  RDD.  Assign  a  different  priority 
order  to  each  requirement  (1  means  first  priority).  Run  the  model  and  check  cargo  itineraries 
to  determine  whether  the  cargos  were  moved  according  to  the  specified  priority  order. 

DATA  COLLECTION  REQUIREMENTS:  Need  cargo  Itineraries  for  selected  requirements 
(including  name  of  lift  vehicle).  May  need  cruise  speeds  of  lift  vehicles  used  to  transport  the 
cargos. 

EVALUATION  CRITERIA:  Cargos  with  higher  priority  should  be  delivered  before  cargos  with 
lower  priority  if  their  RDD  is  the  same. 
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GDAS  IV&V  TEST  CASE  #  1-16 


IV&V  ISSUE:  Capability  to  expand  GDAS  geographic  data. 
GDAS  SUBSYSTEM:  Database. 


REQUIREMENT  SOURCE:  GDAS  SDS  para  2.2. 

REQUIREMENT  STATEMENT:  GDAS  will  simulate  an  unlimited  number  of  theaters  or 
contingency  areas. 

TEST  OBJECTIVE:  Confirm  that  Stanley  Associates*  representation  of  the  globe  by  700  nodes 
can  be  expanded  by  analysts  to  add  new  port  facilities. 

TEST  PROCEDURES:  Add  air  and  sea  ports  to  an  existing  scenario.  Add  one  APOD  and  one 
SPOD  to  a  theater  that  is  used  in  the  scenario.  Also  add  one  APOE  and  one  SPOE  to  a 
CONUS  area  from  which  requirements  move  to  that  theater.  (Give  the  new  ports  capabilities 
similar  to  the  existing  ports.)  Link  the  new  ports  to  existing  intermediate  nodes  in  the  area. 

Run  the  model  and  check  that  the  new  ports  are  used. 

ALTERNATE  PROCEDURE:  Add  a  set  of  cargo  requirements  to  an  existing  scenario  for 
delivery  In  an  area  not  used  in  prior  runs  (e.g.,  Antarctica).  Add  nodes  and  links  to  expand  the 
transportation  network  In  that  area.  This  procedure  would  require  more  extensive  data  base 
modification  than  the  previous  procedure. 

DATA  COLLECTION  REQUIREMENTS:  Review  itineraries  of  requirements  destined  to  a 
specific  theater  in  a  prior  run.  Identify  ports  and  routes  used  In  the  prior  run  so  new  ports  can 
be  established  in  the  immediate  proximity.  Check  itineraries  of  requirements  moved  to  the 
same  theater  In  the  excursion. 


EVALUATION  CRITERIA:  The  added  ports  should  be  used  to  move  cargo  to  the  selected 
theater. 
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GDAS  IV&V  TEST  CASE  #  1-17 


IV&V  ISSUE:  Compile  graphic  output  from  different  runs. 

GOAS  SUBSYSTEM:  Database. 

REQUIREMENT  SOURCE:  GDAS  SDS  para  2.2. 

REQUIREMENT  STATEMENT:  In  addition  to  the  capability  of  producing  standard  reports,  the 
model  will  be  supported  by  an  independent  DBMS  which  will  allow  the  analyst  to  quickly 
perform  ad  hoc  queries  concerning  particular  model  runs. 

TEST  OBJECTIVE:  Confirm  that  the  Paradox  DBMS  can  merge  data  from  several  GDAS  runs 
Into  a  single  table  or  graph. 

TEST  PROCEDURES:  Select  or  create  a  set  of  at  least  three  related  GDAS  scenarios  that 
have  notable  differences  in  a  selected  MOE  between  the  runs.  Ensure  that  each  run's  files  are 
in  a  separate  directory.  Use  the  GDAS  menu  system  to  extract  data  on  the  selected  MOE  from 
each  run  and  combine  the  data  into  a  single  table.  Graph  the  results.  Compare  the  combined 
table  and  graph  with  output  from  the  individual  runs. 

DATA  COiXECTlON  REQUIREMENTS:  Data  on  the  selected  MOE  from  each  run.  A 
combined  table  showing  ail  of  the  data  from  the  Individual  runs.  Graphs  of  the  selected  MOE 
from  each  run  and  from  the  combined  table. 

EVALUATION  CRITERIA:  GDAS  should  allow  the  analyst  to  combine  the  data  from  separate 
runs.  The  data  in  the  combined  table  should  be  the  same  as  data  extracted  from  the  separate 
runs. 
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IV&V  ISSUE:  Propagation  of  packaged  cargo  deliveries  to  UlC  closure  dates. 

GOAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GDAS  SDS  para  5.17. 

REQUIREMENT  STATEMENT:  The  analyst  can  specify  ranges  such  as  5-day  accumulated 
packages  based  on  ROD.  NOTE:  The  original  UlC  lev^  movement  requirements  are  retained 
to  perform  unpackaging  of  the  final  schedule  for  input  to  the  combat  simulation  models. 

TEST  OBJECTIVE:  Confirm  that  when  cargos  are  packaged  for  transport  the  visibility  of  the 
disaggregated  movement  requirement  is  retained  in  the  final  unit  closure  date. 

TEST  PROCEDURES:  Select  an  existing  scenario  that  does  not  use  cargo  packaging  (RLD 
packaging  range  and  RDD  packaging  range  are  set  in  table  PARAM).  Identify  a  set  of 
requirements  where  packaging  is  feasible  based  on  RLO  and  POEs  near  cargo  origin. 
(Transportation  graphics  may  be  helpful  for  this  step.)  Set  ranges  in  table  PARAM  for 
packaging  based  on  RLO.  Identify  another  set  of  requirements  where  packaging  is  feasible 
based  on  ROD  and  POOs  near  cargo  destination.  Set  ranges  in  table  PARAM  for  packaging 
based  on  ROD.  Run  the  model  and  calculate  unit  (TPSN)  closure  based  on  all  requirements  to 
compare  with  the  closure  date  reported  by  the  model.  Also  check  that  movement 
requirements  were  packaged  as  intended. 

NOTE:  GOAS  design  specification  (para  5.17)  implies  that  any  subset  of  movement 
requirements  (e.g.,  Air  Force  resupply)  can  be  selected  for  packaging.  The  data  dictionary 
does  not  seem  to  offer  this  capability. 

DATA  COLLECTION  REQUIREMENTS:  Movement  requirements  data  Including  origin,  RLO, 
destination,  and  ROO.  Closure  required  percentages  (table  REQTYPE)  to  calculate  closure 
dates.  Cargo  itineraries  (including  name  of  lift  vehicle)  to  confirm  cargo  was  packaged. 

EVALUATION  CRITERIA:  Cargo  should  be  packaged  as  indicated  by  input  parameters. 
Closure  dates  computed  in  post-run  queries  (including  packaged  cargo)  should  match  closure 
dates  computed  by  the  model  (table  REQUIRE). 


GDAS  IV&V  TEST  CASE  #  1-19 


iV&V  ISSUE:  Balancing  cargo  lateness  against  lift  asset  utiiization. 

GDAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GDAS  SOS  para  5.7. 

REQUIREMENT  STATEMENT:  A  variety  of  penalty  Actors  are  used  to  evaluate  alternative 
cargo/ship  assignments  for  scheduling.  These  penalty  factors  define  tradeoffs  between 
multiple  objective  function  criteria  such  as  cargo  timeliness  and  ship  utilization. 

TEST  OBJECTIVE:  Use  relatively  higher  values  of  the  input  ‘new  ship  penalty*  to  cause 
greater  utilization  of  ship  capacity. 

TEST  PROCEDURES:  Compare  average  percent  fill  per  ship  in  three  GDAS  runs  where  the 
only  change  between  runs  Is  the  value  of  the  new  ship  penalty.  Indeterminate  or  unexplainable 
results  may  require  more  model  runs. 

NOTE:  This  test  can  also  confirm  the  capability  to  combine  data  from  different  runs  in  a  table 
or  graph. 

DATA  COLLECTION  REQUIREMENTS:  Need  percent  fill  by  ship  type  for  each  run  (table 
RPTSTYPE). 

EVALUATION  CRITERIA:  Changes  in  the  average  percent  fill  by  ship  type  should  be  Inversely 
proportional  to  changes  in  the  ‘new  ship  penalty.* 
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GDAS  IV&V  TEST  CASE  #  1-20 


IV&V  ISSUE:  Menu  system  ooeration  and  functions. 


GOAS  SUBSYSTEM:  Menu. 

REQUIREMENT  SOURCE:  GOAS  SOS  para  2.2. 

REQUIREMENT  STATEMENT:  GOAS  will  Include  full  menu-driven  operation  in  all  of  its 
functions,  and  a  command  language  bypassing  the  menu  system.  The  analyst  will  have  the 
option  of  using  single  key  presses  to  navigate  through  the  entire  menu  system. 

TEST  OBJECTIVE:  Confirm  that  the  GOAS  Menu  System  operates  as  described  in  the  GOAS 
Oesign  Specification  and  satisfies  the  requirements  described  above.  Other  tests  will  provide 
opportunities  to  evaluate  detailed  menu  functions,  but  this  test  will  systematically  explore  the 
major  functions  of  the  main  menu,  the  scenario  menu,  and  the  transportation  model  menu,  and 
the  utilities  menu. 


TEST  PROCEDURES:  Review  the  required  function  and  the  designed  function  of  each  menu 
option  shortly  before  the  test  session.  (Also  consult  user’s  manual  if  available.)  Activate  each 
function  arxf  observe  the  results.  Repeat  as  necessary  to  confirm  that  the  function  operates  as 
required. 


DATA  COLLECTION  REQUIREMENTS:  Observations  on  the  functionality  of  each  major  menu 
function. 


EVALUATION  CRITERIA:  The  GOAS  Menu  System  should  include  the  functions  required  by 
the  GDAS  FD.  Each  menu  function  should  operate  as  described  in  the  GDAS  Design 
Specification  (or  user's  manual,  if  available). 
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IV&V  ISSUE:  Functions  of  interactive  graphics  system. 

GOAS  SUBSYSTEM:  Transportation  Modei/Presentation  Graphics. 

REQUIREMENT  SOURCE:  GOAS  SOS  para  2.2. 

REQUIREMENT  STATEMENT:  GOAS  will  maximize  the  use  of  graphics  to  illustrate  progress 
as  well  as  the  results  of  the  simulation.  The  graphics  capability  will  consist  of  both 
Presentation  Graphics  and  Transportation  Graphics.  The  graphics  capability  will  be  linked  with 
the  DBMS. 

TEST  OBJECTIVE:  Confirm  that  GOAS  offers  the  required  data  manipulation  and  analysis 
capabilities.  Evaluate  the  level  of  difficulty  in  data  access,  analysis,  and  output  through  GOAS 
interactive  graphics.  The  GOAS  Design  Specification  describes  the  required  interactive 
graphics  capabilities  as  ‘presentation  graphics*  and  transportation  graphics*  accessible  under 
the  transportation  model  menu.  This  test  will  focus  on  those  functions. 

TEST  PROCEDURES:  Review  details  of  each  graphics  function  In  the  GDAS  Design 
Specifications  and  user’s  manual  (if  available)  shortly  before  the  function  is  to  be  tested.  Use 
presentation  graphics  to  display  results  of  data  searches  and  manipulations,  including  standard 
and  ad  hoc  queries.  Use  transportation  graphics  to  show  deployment  status  at  several  time 
points  in  the  simulation  (from  a  previous  run).  Print  samples  of  both  tabular  and  graphical 
output  for  comparison  with  screen  displays.  Evsduate  level  of  difficulty  to  produce  graphics  and 
quality  of  graphics  for  analysis. 

DATA  COLLECTION  REQUIREMENTS:  These  tests  can  be  performed  with  any  existing 
GDAS  output. 

EVALUATION  CRITERIA:  All  requirements  described  above  should  be  satisfied  by  GDAS 
presentation  graphics  or  transportation  graphics.  Graphics  products  should  be  suitable  for 
analysis  and  presentation. 


IV&V  ISSUE:  Exposure-related  attrition  of  lift  vehicles  and  cargo. 


GDAS  SUBSYSTEM:  Transportation  Model. 
REQUIREMENT  SOURCE:  GDAS  SOS  para  5.14. 


REQUIREMENT  STATEMENT:  Attrition  submodels  on  travel  links  are  expressed  in  terms  of  a 
search/attack/destroy  exposure  formulation  using  time  dependent  exponential  attrition 
probabilities. 

TEST  OBJECTIVE:  Confirm  that  the  exposure-related  attrition  (on  travel  links)  in  GDAS 
operates  as  planned.  The  cargo  actually  on  board  an  attrited  vehicle  should  also  be  attrited. 

TEST  PROCEDURES:  Query  the  output  from  one  GDAS  run  where  exposure-related  attrition 
is  enabled.  The  following  steps  should  provide  the  necessary  information: 

o  Identify  all  attrited  vehicles 

o  Identify  all  cargo  loaded  on  each  vehicle  at  time  of  loss 
0  Confirm  that  the  identified  cargo  is  attrited  before  reaching  POD 
o  Confirm  that  no  other  cargo  is  attrited  before  reaching  POD. 

DATA  COLLECTION  REQUIREMENTS:  List  of  attrited  vehicles  and  attrited  cargo.  Itineraries 
of  attrited  vehicles,  including  cargo  loaded  and  unloaded  at  each  stop. 


EVALUATION  CRITERIA:  Three  criteria  will  be  used  on  this  test: 

o  The  cargo  loaded  on  the  attrited  lift  vehicles  at  the  time  of  attrition  should  not  arrive  at 
POD. 

o  The  quantity  of  cargo  attrited  should  match  the  quantity  of  cargo  loaded  on  the  lift  vessel 
at  the  time  of  its  loss. 

o  No  other  cargo  should  be  removed  from  the  simulation  unless  it  is  attrited  at  a  port. 
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iV&V  ISSUE:  Aerial  refueling  on  airlift  missions. 


GDAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GDAS  SDS,  para  5.4.1. 

REQUIREMENT  STATEMENT:  GDAS  transportation  network  nodes  may  represent  origins, 
destinations,  airports,  seaports,  truck  or  rail  terminals,  airdrop  nodes,  air  refueling  points,  etc. 

TEST  OBJECTIVE:  Verify  aerial  refueling  capability  for  GDAS  airlift  missions. 


TEST  PROCEDURES:  Choose  a  GDAS  run  in  which  airlift  missions  use  refueling  stops  (e.g., 
CONUS  to  Persian  Gulf).  Create  an  aerial  refueling  node  bisecting  a  long  link  such  as  the 
transatlantic  teg.  Run  the  model  again  and  check  the  output  for  aircraft  visiting  the  aerial 
refueling  node. 


DATA  COLLECTION  REQUIREMENTS:  Identify  the  cargos  on  aircraft  using  the  aerial 
refueling  node  and  their  transit  time  from  POE  to  POO.  Compare  transit  times  for  the  same 
cargos  (if  airlifted)  in  the  base  run. 

NOTE:  Check  whether  this  procedure  would  be  simplified  by  using  a  "special  mission." 

EVALUATION  CRITERIA:  Aerial  refueling  nodes  should  be  used  in  lieu  of  landing  for  fuel  only. 
Airlift  transit  times  (POE  •  POD)  should  decrease  when  aerial  refueling  is  used. 
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IV&V  ISSUE:  Enroute  refueling  stops  on  airlift  missions. 

GDAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GDAS  SDS  para  5.8. 

REQUIREMENT  STATEMENT:  Intermediate  refueling  stops  are  treated  explicitly  for  airlift 
since  refueling  can  significantly  affect  tradeoffs  between  average  block  speed  versus  payloads. 

TEST  OBJECTIVE:  Confirm  that  GDAS  airlift  missions  use  enroute  refueling  stops  by 
examining  airlift  itineraries  in  GDAS  output  data. 

TEST  PROCEDURES:  Choose  a  run  where  distances  between  origin  and  destination  for 
cargo  traveling  by  airlift  exceeds  the  input  critical  leg  lengths  of  airlift  assets.  Select  a 
movement  requirement  with  cargo  designated  for  airlift  mode  such  that  the  origin  to  destination 
distance  is  greater  than  the  input  critical  leg  length  for  airlift  assets.  Identify  the  aircraft  that 
moved  the  selected  cargo  and  check  their  itineraries  for  stops  where  they  only  refuel  and  do 
not  load  or  unload. 

DATA  COLLECTION  REQUIREMENTS:  Range  at  payload  (table  ACFTYPE)  for  each  aircraft 
type.  Requirement  ID,  cargo  (or  PAX)  intertheater  mode,  origin,  and  destination  from  table 
REQUIRE.  Latitude  and  longitude  of  origin  and  destination  nodes  from  table  NODEREF  (to 
estimate  total  travel  distance).  Vehicles  and  trip  numbers  from  table  RPTITIN  for  all  cargos 
related  to  the  selected  movement  requirement.  Stops  and  reasons  for  stops  Cis  unload?"  and 
‘is  refuel?"  data  fields)  in  each  trip  from  table  STOP. 


EVALUATION  CRITERIA:  Trip  itineraries  should  contain  enroute  stops  with  "yes"  for  the  ‘Is 
refuel?"  field  and  "no"  for  the  "Is  unload?"  field. 


IV&V  ISSUE:  Routing  of  sealift  missions. 


GDAS  SUBSYSTEM:  Transportation  Model. 


REQUIREMENT  SOURCE:  GOAS  SOS  para  5.5. 

REQUIREMENT  STATEMENT:  The  GOAS  planning  process  uses  a  multimodal,  shortest 
path/dynamic  programming  algorithm  to  flow  each  movement  across  the  transportation 
network  aixf  assign  transport  modes  and  routes  based  on  nominal  travel  times  and  delays, 
without  considering  individual  vehicle  assignments.  The  planning  process  evaluates  major 
tradeoffs  between  timely  delivery  of  requirements  and  efficient  use  of  costly  vehicle  assets  in 
selecting  modes  and  routes. 

TEST  OBJECTIVE:  Confirm  that  the  GOAS  scheduler  plans  trips  using  the  shortest  available 
routes  over  the  input  Intermodal  transportation  network. 


TEST  PROCEDURES:  Randomly  select  sealift  trips  with  and  without  enroute  load/unload 
stops  from  table  STOP.  Use  the  GOAS  transportation  graphics  system,  if  available,  to  map 
each  trip  and  all  nodes  available  along  the  route  from  origin  to  destination.  (Procedures  for 
using  transportation  graphics  are  unknown.)  If  transportation  graphics  are  not  available,  query 
latitude  and  longitude  Adds  in  table  NOOE  to  identify  nodes  along  the  route  arxl  cross- 
reference  with  table  FACILITY  to  And  sealift  ^ciiities.  In  cases  where  a  shorter  route  appears  to 
be  available,  check  tables  NODE,  NODEUNK,  FACTYPE,  and  EXCLUDE  to  determine  whether 
there  are  constraints  that  deny  use  of  the  node  by  that  trip. 


DATA  COLLECTION  REQUIREMENTS:  The  basic  data  requirements  for  this  test  are  the  trip 
data  from  table  STOP  and  other  available  facilities  along  the  route.  The  extent  of  data 
collection  requirements  will  depend  on  the  availability  and  functions  of  GDAS  transportation 
graphics. 


EVALUATION  CRITERIA:  The  selected  ship  routes  should  be  the  shortest  avaOabie  route 
between  cargo  origin  and  destination. 
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IV&V  ISSUE:  Rexibility  to  define  new  vehicle  types. 

GDAS  SUBSYSTEM:  Database. 

REQUIREMENT  SOURCE:  GDAS  SDS  para  5.2. 

REQUIREMENT  STATEMENT:  GDAS  includes  capabilities  to  define,  in  the  database,  more 
detailed  cargo  types  with  additional  units  of  measure,  more  detailed  vehicle  compartments 
(multiple  compartments  each  having  multiple  units  of  measure  and  capacity  limits  with  stow 
factors  matched  to  cargo  types). 


TEST  OBJECTIVE:  Add  a  new  vehicle  type  to  a  GDAS  scenario  and  confirm  that  it  Is  used  by 
the  model. 


TEST  PROCEDURES:  Enter  a  new  vehicle  type  in  table  VEHTYPE.  For  the  purpose  of  the 
test,  make  its  time  arxJ  distance  penalties  low  compared  with  other  vehicles.  Enter  two  types 
of  compartments  for  the  vehicle  (tables  VCPTTYPE  and  CPTTYPE)  and  use  a  different  measure 
for  each  compartment  (table  CPTMEAS).  Enter  the  compartment  stow  factors  in  table 
STOWFACT  and  stow  penalties  in  table  STOWPEN  Enter  the  vehicle  characteristics  in  the 
appropriate  table:  ACFTYPE  for  airlift  or  SHIP  for  sealift  Table  AIRSQUAD  should  be 
completed  for  an  airlift  vehicle.  Hourly  load  and  unload  rates  should  be  entered  in  table 
LOADRATE.  Make  a  run  and  check  that  GDAS  uses  the  new  vehicle  type  (table  RPTVTYPE). 

DATA  COLLECTION  REQUIREMENTS:  Obtain  or  develop  vehicle  capacities,  characteristics, 
and  stow  factors  before  starting  the  test  Check  for  vehicle  names  and  cargo  quantities  in 
table  RPTVTYPE. 


EVALUATION  CRITERIA:  GDAS  should  use  the  new  vehicle  type  to  transport  cargo. 
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GDAS  IV&V  TEST  CASE  #  2-27 


IV&V  ISSUE:  Compatibility  of  ships  atxl  seaports. 

GDAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GDAS  SDS  para  5.4.2. 

REQUIREMENT  STATEMENT:  Facilities  can  be  constrained  as  to  whether  refueling  is 
permitted  and  which  types  of  vehicles  can  be  handled  (e.g.,  C-I7s  may  be  unable  to  land  at 
certain  airports,  or  NATO  fleets  may  be  excluded  from  Korean  seaports,  or  military  aircraft  only 
are  permitted  at  airdrop  facilities  which  have  reduced  unload  rates). 

TEST  OBJECTIVE:  Observe  the  matching  of  facilities  and  vehicles  in  GDAS. 

TEST  PROCEDURES:  Check  tables  SEAPORT,  EXCLUDE,  and  FACIUTY  to  get  the  lift  modes 
supported  by  each  seaport  facility  and  any  vehicle  or  cargo  exclusions.  Use  this  information  as 
a  basis  for  searches  in  table  RPTITIN  to  determine  whether  any  prohibited  matches  occur 
among  seaports,  ships,  and  cargo  categories.  Ship  draft,  length,  and  beam  (table  SHIP) 
should  also  be  compared  with  the  maximum  allowable  at  seaports. 

DATA  COLLECTION  REQUIREMENTS:  List  of  faculties  that  support  sealift  from  table 
FACILITY.  List  of  exclusions  affecting  these  facilities  from  table  EXCLUDE. 

EVALUATION  CRITERIA:  No  prohibited  matches  should  occur. 
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GDAS  IV&V  TEST  CASE  #  2-28 
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IV&V  ISSUE:  Compatibility  of  aircraft  and  airports. 

GDAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GOAS  SOS  para  5.4.2. 

REQUIREMENT  STATEMENT:  Facilities  can  be  constrained  as  to  whether  refueling  Is 
permitted  and  which  types  of  vehicles  can  be  handled  (e.g.,  C-I7s  may  be  unable  to  land  at 
certain  airports,  or  NATO  fleets  may  be  excluded  from  Korean  seaports,  or  military  aircraft  only 
are  permitted  at  airdrop  facilities  which  have  reduced  unload  rates). 

TEST  OBJECTIVE:  Confirm  that  GOAS  will  not  schedule  aircraft  to  use  airport  facilities  that  do 
not  meet  aircraft  requirements  such  as  runway  width,  length,  and  composition,  or  facilities  for 
specific  aircraft  types. 

TEST  PROCEDURES:  Select  a  combination  of  aircraft  type  and  airport  in  which  the  airport 
runway  length  is  less  than  the  minimum  runway  required  for  the  aircraft.  Set  up  a  specif 
mission  (in  table  REQUIRE)  for  an  air  transportable  movement  requirement  with  the  selected 
airport  as  its  destination.  Use  tables  MISSION  and  AIRSQUAD  to  assign  a  squadron  of  the 
selected  aircraft  to  this  special  mission.  Make  a  run  and  check  output  data  to  determine 
whether  the  cargo  was  transported,  and  if  so,  check  the  destination  airport. 

DATA  COLLECTION  REQUIREMENTS:  Get  airport  runway  length  from  table  AIRPORT  and 
aircraft  runway  requirement  from  table  ACFTYPE.  Get  cargo  movement  dates  and  unload  stop 
from  table  CARGO. 


EVALUATION  CRITERIA:  The  special  mission  aircraft  should  not  fly  the  selected  cargo  Into 
the  selected  airport 
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IV&V  ISSUE:  Vehicle  load  and  unload  rates. 


GOAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GDAS  SOS  para  5.4.6. 

REQUIREMENT  STATEMENT:  Vehicle  types  and  compartment  types  are  defined  genericaily 
for  each  transport  mode  in  order  to  specify  load  rates,  stow  factors,  refueling  rates,  and  vehicle 
utilization  pendties  within  a  common  structure  for  the  scheduling  model.  Load  and  unload 
rates  are  specified  as  a  function  of  vehicle  type,  facility  type,  and  cargo  type. 

TEST  OBJECTIVE:  Confirm  that  GOAS  loads  and  unloads  lift  assets  at  rates  consistent  with 
their  input  load/unioad  rates. 

TEST  PROCEDURES:  Compile  load/unload  times  and  cargo  quantities  for  all  loading  or 
unloading  stops  in  a  run.  Olvide  cargo  quantities  by  houriy  load  and  unload  rates  for  the 
vehicle  type  to  determine  whether  the  actual  times  are  consistent  with  the  input  maximums. 

DATA  COLLECTION  REQUIREMENTS:  Ship  name,  cargo  quantities,  begin  and  end  times, 
and  port  facility  for  each  cargo  load/unload  activity  from  table  RPTITIN.  Ship  type  from  table 
SHIP.  Facility  type  from  table  FACILITY.  Hourly  load/unload  rates  from  table  LOADRATE. 

EVALUATION  CRITERIA:  Computed  actual  load  rates  should  not  exceed  input  maximum  load 
rates. 

NOTE:  The  current  data  fields  In  the  GOAS  data  dictionary  Indicate  that  the  time  loading 
operations  begin  and  end  is  not  reported.  Only  the  begin  and  end  dates  are  reported. 
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IV&V  ISSUE:  Facility  throughput  constraints  for  cargo. 

GDAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GOAS  SDS  para  5.4.2. 

REQUIREMENT  STATEMENT:  Each  facility  has  cargo  or  vehicle  throughput  measures  based 
on  facility  type  and  transport  mode,  e.g.,  max  cargo  tonnage  per  day,  max  number  of  sorties 
or  vehicles  per  day,  and  maximum  on  ground  (for  airlift)  or  in  berth  (for  sealift). 

TEST  OBJECTIVE:  Check  sealift  facility  cargo  loading  and  unloading  activities  by  day  to 
determine  whether  the  facility  throughput  limits  are  exceeded. 

TEST  PROCEDURES:  Cross-reference  tables  CARGO  and  STOP  to  get  the  start  date,  end 
date,  and  cargo  quantity  for  each  cargo  loaded  or  unloaded  at  each  sealift  facility.  Query  the 
result  for  daily  totals  exceeding  the  facility  limits  (table  FACUMIT). 

DATA  COLLECTION  REQUIREMENTS:  Cargo  quantity,  load/unload  days,  and  stop  numbers 
from  table  CARGO.  Facility  name  for  each  stop  from  table  STOP.  Facility  limits  from  table 
FACUMIT. 


EVALUATION  CRITERIA:  Total  cargo  processed  per  day  at  any  facility  should  not  exceed  the 
facility  throughput  limit. 


IV&V  ISSUE:  Facility  throughput  constraints  for  vehicles. 

GDAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GDAS  SOS  para  5.4.2. 

REQUIREMENT  STATEMENT:  Each  facility  has  cargo  or  vehicle  throughput  measures  based 
on  facility  type  and  transport  mode,  e.g.,  max  cargo  tonnage  per  day,  max  number  of  sorties 
or  vehicles  per  day,  and  maximum  on  ground  (for  airlift)  or  in  berth  (for  sealift). 

TEST  OBJECTIVE:  Confirm  that  GDAS  limits  the  number  of  ships  per  day  using  a  seaport 
facility. 

TEST  PROCEDURES:  Query  table  STOP  in  any  GDAS  scenario  to  find  a  seaport  facility  that 
is  heavily  used.  In  table  FACILITY,  change  the  Max  Vehicles  in  Facility  to  two.  Rerun  the 
model  to  determine  whether  the  vehicle  throughput  constraint  was  effective.  (See  test  3-73.) 

DATA  COLLECTION  REQUIREMENTS:  Get  the  facility  node,  vehicle  arrive  day,  and  vehicle 
depart  day  from  table  STOP. 

EVALUATION  CRITERIA:  There  should  not  be  more  than  two  ships  at  the  selected  seaport 
facility  on  any  one  day. 
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IV&V  ISSUE:  User-specified  cargo  packaging  criteria. 

GDAS  SUBSYSTEM:  Database. 

REQUIREMENT  SOURCE:  GDAS  SDS  para  5.17. 

REQUIREMENT  STATEMENT:  The  query  capability  of  the  underlying  database  can  be  used 
to  perform  packaging  based  on  user-specified  criteria.  First  the  CAA  analyst  is  able  to  select  or 
query  any  subset  of  movement  requirements  (e.g.,  Air  Force  resupply)  before  applying  a  given 
set  of  packaging  rules.  The  analyst  can  use  the  database  query  tools  to  redefine  or  merge 
cargo  categories  prior  to  packaging  if  a  m  jre  aggregated  analysis  is  desired. 

TEST  OBJECTIVE:  Use  GDAS  database  capabilities  to  package  a  set  of  movement 
requirements. 

TEST  PROCEDURES:  To  be  determined.  Table  PARAM  has  fields  to  input  a  number  of  days 
to  use  as  a  RLD  packaging  range  or  as  a  RDD  packaging  range.  There  is  apparently  no 
straightforward  capability  to  package  specific  movement  requirements  within  GDAS.  (The 
capability  to  redefine  cargo  categories  is  available,  but  the  original  input  categories  would  be 
lost.) 

DATA  COLLECTION  REQUIREMENTS:  To  be  determined.  The  appropriate  data  fields  and 
data  entry  procedures  must  be  obtained  from  additional  GDAS  documentation  or  from  the 
model  developers. 

EVALUATION  CRITERIA:  To  be  determined.  The  primary  criterion  for  this  test  should  be 
based  on  delivery  profiles  of  packaged  cargo.  A  secondary  criterion  may  be  used  for  visibility 
of  the  cargo  delivery  dates  at  different  aggregation  levels  (UlC,  TPSN,  etc.). 


GDAS  IV&V  TEST  CASE  #  2-33 
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IV&V  ISSUE:  Analyst-assigned  cargo  transport  modes. 

GDAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GDAS  SDS  para  5.4.3. 

REQUIREMENT  STATEMENT:  Movement  requirements  may  exhibit  relationships  which  must 
be  coordinated  during  scheduling.  For  example,  movements  may  have  pre-assigned  transport 
modes,  POE/POD  ports,  or  staging  nodes  with  a  predefined  ALD  (Available  to  Load  Date), 
EAO  (Earliest  Arrival  Date),  and  LAD  (Latest  Arrival  Date)  as  specified  in  the  REQNODE  table. 

TEST  OBJECTIVE:  Confirm  that  GDAS  complies  with  specific  lift  modes  input  by  the  user. 

TEST  PROCEDURES:  Perform  this  test  by  modifying  an  existing  GDAS  scenario.  Randomly 
select  movement  requirements  that  normally  travel  via  airlift  (e.g.,  PAX)  and  assign  them  a 
Cargo  Intertheater  Mode  of  sealift  (table  REQUIRE).  Randomly  select  movement  requirements 
that  normally  travel  via  sealift  (e.g.,  bulk  ammunition)  and  assign  them  a  Cargo  Intertheater 
Mode  of  airlift.  Run  the  modified  scenario  and  check  whether  the  lift  mode  for  the  selected 
movement  requirements  complied  with  the  input  assignments  (use  table  RPTITIN). 

DATA  COLLECTION  REQUIREMENTS:  Data  from  any  existing  GDAS  scenario  can  be  used 
for  this  test. 


EVALUATION  CRITERIA:  Each  cargo  associated  with  the  selected  movement  requirements 
should  be  transported  by  the  assigned  iift  mode. 
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GDAS  IV&V  TEST  CASE  #  2-34 


IV&V  ISSUE:  Analyst-assigned  cargo  staging  stops. 

GDAS  SUBSYSTEM:  Transportation  Model. 

PtEQUIREMENT  SOURCE:  GDAS  SDS  para  5.4.3. 

REQUIREMENT  STATEMENT:  Cargo  movements  may  have  pre-assigned  transport  modes, 
POE/POD  ports,  or  staging  nodes  with  a  p.edefined  ALO  (Available  to  Load  Date),  EAD 
(Earliest  Arrival  Date),  and  LAD  (Latest  Arrival  Date)  as  specified  in  the  REQNODE  table.  If 
multiple  requirements  are  staged  or  assembled  together  then  an  assembly  dependency  exists 
in  which  successor  cargos  are  delayed  until  all  predecessor  cargos  arrive,  possibly  with  delay 
times  for  assembly  and  a  latest  staging  depart  day  as  specified  in  the  STAGE  table. 

TEST  OBJECTIVE:  Confirm  that  GDAS  allows  analysts  to  link  movement  requirements  for 
consolidation  or  assembly  at  a  specific  node. 

TEST  PROCEDURES:  Select  movement  requirements  with  similar  RDDs  to  be  consolidated 
during  a  run.  Enter  the  requirements  in  table  REQNODE  and  assign  a  stage  name.  Select  an 
intermediate  staging  node  with  appropriate  facilities  and  compute  a  node  EAD,  LAD,  and  delay 
time  consistent  with  the  RDD  and  distance  to  destination.  Enter  the  delay  days  and  stage 
latest  depart  day  in  table  STAGE.  Run  the  scenario  ard  check  the  load  stops,  unload  stops, 
and  related  dates  in  table  CARGO  to  determine  whether  GDAS  complied  with  the  input  staging 
parameters. 

DATA  COLLECTION  REQUIREMENTS:  Described  in  test  procedures. 


EVALUATION  CRITERIA:  Each  cargo  associated  with  the  selected  requirements  should  transit 
the  staging  node  during  the  input  staging  dates.  (NOTE:  Cargos  need  not  visit  the  staging 
node  after  the  latest  depart  date  in  table  STAGE.) 
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IV&V  ISSUE;  Special  mission  assignments  for  lift  assets. 


GDAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GDAS  SDS  para  5.4.8. 

REQUIREMENT  STATEMENT:  Special  missions  can  be  defined  which  restrict  aircraft 
squadrons,  ship  fleets,  or  individual  ships  to  a  particular  set  of  movement  requirements  for  a 
specified  period  of  time. 

TEST  OBJECTIVE:  Check  out  the  GDAS  special  mission  feature  that  reserves  ships  to 
transport  only  cargo  designated  by  the  special  mission  code.  (Special  mission  for  airlift  is  used 
in  another  test.) 


TEST  PROCEDURES:  Set  a  special  mission  code  for  a  large  movement  requirement  in  table 
REQUIRE.  Use  tables  MISSION  and  SHIP  to  assign  only  one  ship  for  the  special  mission 
cargo.  Check  table  RPTITIN  to  identify  the  vehicle(s)  moving  the  cargo. 


DATA  COLLECTION  REQUIREMENTS:  Locate  cargo  by  requirement  ID  in  table  RPTITIN  and 
get  the  name  of  the  ship  transporting  the  cargo  from  the  same  table. 

EVALUATION  CRITERIA:  Special  mission  cargo  should  be  transported  only  on  the  special 
mission  ship. 
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GDAS  IV&V  TEST  CASE  #  2-36 


IV&V  ISSUE:  Scheduler  compliance  with  input  movement  dates. 

GOAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE.  GDAS  SDS  para  2.1. 

REQUIREMENT  STATEMENT:  The  planning  phase  introduces  a  concept  referred  to  as  the 
Target  Lift  Date  (TLD).  The  TLD  is  computed  for  each  movement  requirement,  and  is  that  date 
at  which  the  movement  requirement  must  begin  its  journey  to  its  destination  in  order  to  arrive 
by  the  Required  Delivery  Date  (RDD). 

TEST  OBJECTIVE:  Confirm  that  the  GDAS  scheduler  complies  with  input  cargo  availability 
dates  and  required  delivery  dates. 

TEST  PROCEDURES:  Use  the  input  RLD,  EDD,  and  RDD  (table  REQUIRE)  as  measures  for 
this  test.  Query  tables  CARGO,  REQUIRE,  and  RPTITIN  to  compute  the  difference  between 
input  cargo  movement  dates  and  simulated  cargo  movement  dates. 

DATA  COLLECTION  REQUIREMENTS:  Data  from  any  existing  GDAS  scenario  can  be  used 
to  perform  this  test. 


EVALUATION  CRITERIA:  The  input  cargo  movement  dates  and  simulated  movement  dates 
should  have  the  following  relationships: 

o  RDD  -  Cargo  Delivery  Day  =  >  0 
o  Cargo  Delivery  Day  -  EDD  =  >  0 
o  Begin  Load  Day  -  RLD  =  >  0 
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IV&V  ISSUE:  Time-stepped  changes  for  input  parameters. 

GDAS  SUBSYSTEM:  Transportation  Modei. 

REQUIREMENT  SOURCE:  GDAS  SOS  para  5.13. 

REQUIREMENT  STATEMENT:  The  analyst  has  the  ability  to  make  any  characteristics  data 
change  over  time  in  a  surprise  mode  for  the  transportation  modei.  For  example,  total  port 
throughput  can  be  edited  to  change  over  time  on  several  different  dates,  or  sealift  links  may 
change  over  time  to  reflect  canal  closings.  In  the  simulation  model,  the  time-varying  changes 
are  incorporated  into  the  packed  data  itself  on  a  daily  basis,  so  subsequent  accesses  return  the 
changed  value.  These  changes  may  require  re-planning  or  re-scheduling  of  future  cargo 
assignments  in  the  logic. 

TEST  OBJECTIVE:  Confirm  that  GDAS  users  can  input  variations  in  transportation  system 
capabilities  for  specific  time  periods. 

TEST  PROCEDURES:  Use  table  FACILITY  to  test  this  feature.  Select  the  Time  Vary  option 
from  the  Setup  menu  and  set  the  Operating  Hours/Day  for  a  major  port  facility  (or  several 
facilities)  to  zero  over  a  period  of  several  days,  then  back  to  the  starting  value.  Run  the 
modified  scenario  and  check  table  STOP  to  determine  whether  the  facility  was  used  on  open 
days  and  not  used  on  closed  days. 

(QUESTION;  What  data  is  considered  "characteristics  data?" 

DATA  COLLECTION  REQUIREMENTS:  Data  from  any  GDAS  scenario  can  be  used  to 
perform  this  test. 

EVALUATION  CRITERIA:  The  selected  facility  should  not  be  used  while  its  operating  hours 
are  set  at  zero,  but  should  be  used  before  and  after  this  period. 
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IV&V  ISSUE:  Variable  weights  to  accompany  airlifted  PAX. 
GOAS  SUBSYSTEM:  Database. 


REQUIREMENT  SOURCE:  GDAS  COTR. 


REQUIREMENT  STATEMENT:  Could  not  find  this  requirement  in  FD  or  SDS. 

TEST  OBJECTIVE:  Confirm  that  GDAS  has  the  capability  to  assign  the  baggage  weight 
accompanying  airlifted  passengers. 


TEST  PROCEDURES:  To  be  determined.  It  should  be  possible  to  select  requirements  with 
large  number  of  passengers  and  change  the  accompanying  weight.  The  accompanying  weight 
for  this  test  should  be  selected  to  ensure  that  an  aircraft  like  a  0141  would  reach  maximum 
payload  weight  before  the  maximum  number  of  passengers  is  loaded.  As  a  result,  a  0141 
transporting  passengers  for  the  selected  requirement  would  carry  less  than  the  maximum 
number  of  passengers. 

DATA  COLLECTION  REQUIREMENTS:  Table  CARGOCLAS  has  a  field  named  'Has 
Accompanying  Pounds?'  Table  THTRREQ  has  a  field  named  'Accompanying  Gear*  for  non¬ 
carry-on  accompanying  gear  per  passenger.  It  is  not  clear  that  these  fields  have  any  effect  on 
the  loading  of  lift  vehicles. 

EVALUATION  CRITERIA:  To  be  determined.  The  evaluation  criteria  should  be  based  on  the 
expected  GDAS  response  to  input  data  changes  specified  by  the  test  procedures. 
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GDAS  iV&V  TEST  CASE  #  2-39 


IV&V  ISSUE:  User  control  of  scheduling  goals. 

GDAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GDAS  SOS  para  5.7,  5.8. 

REQUIREMENT  STATEMENT:  A  variety  of  penalty  factors  are  used  to  evaluate  alternative 
cargo/ship  assignments  for  scheduling.  These  penalty  factors  define  tradeoffs  between 
multipile  objective  function  criteria  such  as  cargo  timeliness  and  ship  utilization.  Each  penalty 
factor  is  designed  to  control  a  separate  aspect  of  ship  scheduling. . .  Aircraft  scheduling  is 
performed  with  the  same  overall  approach  as  sealift,  with  the  calculation  of  marginal 
cost/benefit  ratios  to  determine  preferred  aircraft  selections. 

TEST  OBJECTIVE:  Confirm  that  factors  designed  to  provide  analyst  control  of  the  GDAS 
scheduler  are  effective  in  meeting  the  scheduler  goals.  These  factors  include  the  foiiowing: 

o  Analyst  RDD 
o  Penalty  factors 
o  Scheduling  horizon 
o  Constraints 
o  Prioritization. 

TEST  PROCEDURES:  The  Information  about  these  factors  in  the  GDAS  SDS  leaves  many 
open  questions  about  the  practical  range  of  values  for  each  factor,  the  Interactions  among 
factors,  and  the  output  measures  affected  by  each  factor.  Tests  of  these  factors  will  involve 
parametric  variation  of  a  single  foctor  and  observation  of  the  changes  In  an  appropriate  MOE. 
Where  possible,  the  run-to-run  changes  will  be  compared  in  both  tabular  and  graphical  form. 
Standard  GDAS  output  reports  will  be  used  to  the  maximum  extent  possible. 

DATA  COLLECTION  REQUIREMENTS:  To  be  determined,  based  on  additional  GDAS 
documentation  or  on  the  results  of  Initial  model  runs. 

EVALUATION  CRITERIA:  The  nature  of  GDAS  response  to  changes  in  the  above  factors 
should  be  consistent  over  a  range  of  values.  Changing  a  fector  should,  within  the  range  of 
model  sensitivity,  should  cause  a  proportional  (or  inversely  proportional)  response  in  the  MOE 
of  interest 
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IV&V  ISSUE:  Notional  intratheater  transport  delays. 


GDAS  SUBSYSTEM:  Transportation  Model. 


REQUIREMENT  SOURCE:  GDAS  SOS  para  5.2. 

REQUIREMENT  STATEMENT:  The  GDAS  design  explicitly  accounts  for  the  coordination  of 
multiple,  interdependent  movements  which  are  characteristic  of  DoD  intermodal  transportation, 
including  cargos  which  are  related  by  precedence  seauenclno  (e.g.,  a  multimodal  staged 
movement  in  which  an  airlift  leg  depends  on  a  prior  sealift  leg),  or  assembly  dependency  (e.g., 
multiple  air/sea  or  POMCUS  movements  which  must  marry  up  at  a  marshalling  or  staging 
location  before  moving  forward),  or  balanced  force  links  (e.g.,  CS/CSS/supply  movements 
which  are  assigned  to  support  a  combat  unit). 

TEST  OBJECTIVE:  Confirm  that  GDAS  has  the  capability  to  represent  in-theater  activities 
such  as  assembly  delays  in  marshalling  areas. 

TEST  PROCEDURES:  Need  to  calculate  the  difference  between  Cargo  Delivery  Day  and 
Cargo  Unload  Day  (table  RPTITIN),  change  selected  marry-up  delay  days  in  table  THTRREQ, 
run  the  modified  scenario,  and  run  the  modified  scenario.  The  difference  between  delivery  day 
and  unload  day  should  reflect  the  change  in  marry-up  delay  days.  (QUESTION;  How  can  you 
make  a  connection  between  Requirement  ID  and  Requirement  Type?) 

DATA  COLLECTION  REQUIREMENTS:  As  described  in  the  test  procedures. 

EVALUATION  CRITERIA:  Marry-up  delay  days  should  be  reflected  in  the  difference  between 
cargo  unload  day  and  cargo  delivery  day. 
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IV&V  ISSUE:  Dynamic  intratheater  resuppiy  aigorithm. 

GOAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GDAS  SOS  para  5.12. 

REQUIREMENT  STATEMENT:  Resupply  demands  are  generated  daily  as  units  arrive  and 
deploy  at  the  destination  based  on  consumption  rates  specified  in  the  database.  Demand  is 
met  first  from  accompanying  (unit)  supplies,  then  from  stockpiles  at  the  destination.  Each 
destination  stockpile  has  a  specified  reorder  level,  minimum  economic  order  quantity,  and  a 
target  inventory  level  for  total  on  hand  plus  on  order,  all  of  which  are  used  to  place  "orders"  at 
supply  origins  when  stockpiles  are  drawn  down  to  the  reorder  level.  The  orders  are  placed 
with  the  nearest  supply  origin  (based  on  shortest  path  calculations)  that  has  sufficient  supply 
quantity,  resulting  in  the  dynamic  generation  of  resupply  movement  requirements.  If  at  any 
time  the  stockpiles  in  the  theater  are  insufficient  to  meet  demands,  the  demands  are  simply 
dropped  with  no  backlogging  in  the  current  formulation. 

TEST  OBJECTIVE:  Confirm  that  QDAS  generates  arxf  fills  intratheater  resup|)ly  demands. 

TEST  PROCEDURES:  Daily  consumption  rates  and  accompanying  days  of  supply  can  be 
entered  in  table  SUPPCONS.  Combat  intensity  and  supply  attrition  can  be  entered  in  table 
SUPPINT.  The  resupply  origins  and  their  production  rates  are  entered  In  table  SUPPORIQ. 
Stockpile  destinations  and  order  quantities  are  in  table  SUPPDEST.  Table  PARAM  has  a  "Do 
Dynamic  Resupply?"  field  used  to  activate  the  dynamic  resupply  process.  Table  REQTYPE  has 
a  "Generate  Resupply?"  field  that  designates  the  requirement  types  for  which  resupply  will  be 
generated.  (QUESTION:  What  controls  the  movement  and  disposition  of  resupply  o^ers?) 

DATA  COLLECTION  REQUIREMENTS:  Need  data  to  fill  the  applicable  fields  described  In  the 
test  procedures.  First  step  is  to  precisely  identify  which  fields  affect  dynamically  generated 
resupply  requirements. 

EVALUATION  CRITERIA:  To  be  determined.  Evaluation  criteria  for  this  test  should  be  based 
on  the  data  changes  prescribed  In  the  test  procedures. 
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IV&V  ISSUE:  Simulation  of  airdrop  operations. 


GDAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GDAS  SDS  para  5.4.1. 

REQUIREMENT  STATEMENT:  GDAS  transportation  network  nodes  may  represent  origins, 
destinations,  airports,  seaports,  truck  or  rail  terminals,  airdrop  nodes,  air  refueling  points,  etc. 

TEST  OBJECTIVE:  Confirm  the  GDAS  airdrop  capability. 

TEST  PROCEDURES:  Set  up  a  movement  requirement  in  table  REQUIRE  for  air  transport 
mode,  using  an  airdrop  facility  (may  have  to  create  the  facility)  as  the  final  destination.  Check 
output  in  table  RPTITIN  to  determine  the  cargo  unload  stop,  unload  day,  and  delivery  day. 

DATA  COLLECTION  REQUIREMENTS:  Get  the  cargo  unload  stop,  unload  day,  aixl  delivery 
day  from  table  RPTITIN. 


EVALUATION  CRITERIA:  Cargo  should  be  unloaded  at  the  airdrop  bcility  and  the  delivery 
date  should  be  the  same  as  the  unload  date. 


IV&V  ISSUE:  Convoy  control  parameters  by  theater. 

GDAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GDAS  SDS  para  5.10. 

REQUIREMENT  STATEMENT:  Data  elements  which  specify  convoying  policy  for  ships  are 
listed  in  Figure  5-9.  (NOTE:  The  data  elements  include  convoy  assembly  and  disassembly 
nodes  in  table  CONVOY,  and  a  convoy  begin  day  in  table  THEATER.)  If  a  movement 
requirement  has  a  destination  In  a  theater  for  which  convoying  operations  have  begun,  and  if  a 
given  ship  must  be  convoyed  based  on  the  convoy  speed  criterion,  then  a  separate  calculation 
is  performed  to  identify  the  nearest  convoy  assembly  node  and  disassembly  node  based  on 
great  circle  distances. 

TEST  OBJECTIVE:  Confirm  that  GDAS  dynamically  forms  ship  convoys  according  to 
parameters  Input  by  the  user. 

TEST  PROCEDURES:  Set  flags  In  table  PARAM  to  do  convoying  and  (optionally)  convoy 
returning  ships.  Enter  dates  to  begin  convoys  and  maximum  ship  speed  to  be  convoyed  in 
table  DESTIN  (per  GDAS  Data  Dictionary,  19  Dec  90)  for  selected  destinations.  All  other  input 
information  for  convoys  is  entered  in  table  CONVOY:  min  and  max  numbers  of  ships  and 
escorts,  convoy  speed  arxl  delay  days,  and  assembly  and  disassembly  nodes.  Convoy  output 
is  in  table  CONVTRIP. 


DATA  COLLECTION  REQUIREMENTS:  Described  in  the  test  procedures. 

EVALUATION  CRITERIA:  Ships  going  to  the  selected  destinations  during  the  convoying 
period  should  travel  In  convoys  unless  they  exceed  the  limitations  for  ship  speed  or  waiting 
time. 


A-46 


IV&V  ISSUE:  Cargo  staging  in  multi-mode  transportation. 

GDAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GDAS  SDS  para  5.4.3. 

REQUIREMENT  STATEMENT:  Cargo  movements  may  have  pre-assigned  transport  modes, 
POE/POD  ports,  or  staging  nodes  with  a  predefined  ALD  (Available  to  Load  Date),  EAD 
(Earliest  Arrival  Date),  arxl  LAD  (Latest  Arrival  Date)  as  specified  in  the  REQNODE  table.  If 
multiple  requirements  are  staged  or  assembled  together  then  an  assembly  dependency  exists 
In  which  successor  cargos  are  delayed  until  all  predecessor  cargos  arrive,  possibly  with  delay 
times  for  assembly  and  a  latest  staging  depart  day  as  specified  in  the  STAGE  table. 

TEST  OBJECTIVE:  Corrfirm  that  staged  cargo  can  use  different  lift  modes  departing  a  staging 
node  than  they  used  to  get  to  the  staging  node. 

TEST  PROCEDURES:  This  test  can  be  performed  concurrently  with  test  2-34.  The  Required 
Mode  to  Node  field  in  table  REQNODE  should  be  completed  for  this  test.  (NOTE:  There  is  no 
place  to  input  a  required  mode  from  the  staging  node.)  (QUESTION:  How  can  the  transport 
modes  in  and  out  of  the  staging  node  be  checked?  Tables  CARGO  and  STOP?) 

DATA  COLLECTION  REQUIREMENTS:  Described  in  test  2-34. 


EVALUATION  CRITERIA:  Some  of  the  staged  cargo  should  use  different  transport  modes 
before  and  after  the  staging  node.  Anticipate  that  cargo  airlifted  to  the  staging  node  may 
depart  by  sealift. 
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IV&V  ISSUE:  Tracking  individual  aircraft  in  output  data. 


GDAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GDAS  SDS  para  5.4.9. 

REQUIREMENT  STATEMENT:  Each  voyage  or  trip  has  an  itinerary  which  is  defined  In  terms 
of  stops  at  ports  or  nodes.  For  each  stop,  the  output  data  includes  arrive  day,  node  or  port, 
facility  type,  depart  day,  and  whether  the  stop  is  for  unloading. . .  For  each  trip,  the  assigned 
vehicle  type  and,  as  appropriate,  the  assigned  ship  or  air  squadron  are  stored. 

TEST  OBJECTIVE:  Confirm  that  analysts  can  follow  the  utilization  of  a  specific  aircraft  in  a 
GDAS  simulation. 


TEST  PROCEDURES:  Link  table  TRIP  and  table  STOP  to  determine  the  itineraries  of  aircraft 
on  missions.  Slack  time  for  a  specific  aircraft  is  not  directly  available  ~  only  total  vehicles 
unused  or  in  slack  by  vehicle  type  (table  RPTVEHDY).  Percent  fill  of  aircraft  is  only  available  as 
an  average  by  vehicle  type  in  table  RPTVTYPE.  (Percent  fill  for  ships  is  available  in  table 
RPTITIN,  but  aircraft  are  not  included  in  this  table.) 

DATA  COLLECTION  REQUIREMENTS:  Output  data  from  any  GDAS  scenario  can  be  used  to 
perform  this  test. 


EVALUATION  CRITERIA:  The  location,  activity,  and  percent  fill  of  any  individual  aircraft  at  any 
time  in  a  GDAS  simulation  should  be  available  in  GDAS  output. 
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IV&V  ISSUE:  Use  of  multiple  ports  in  sealift  missions. 

GDAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GOAS  SDS  para  5.5. 

REQUIREMENT  STATEMENT:  The  scheduling  algorithm  evaluates  the  cargo  characteristics 
and  the  currently  scheduled  vehicle  itineraries  to  assign  the  cargo  to  vehicles  or  transport 
assets,  using  detailed  route  insertion  algorithms  and  “greedy  cargo*  cost/benefit  selection  for 
airlift  and  sealift. 

TEST  OBJECTIVE:  Confirm  use  of  multiple  pickup  and  delivery  stops  for  GOAS  sealift 
missions. 

TEST  PROCEDURES:  Sort  table  RPTITIN  by  ship  name,  trip  number,  and  arrive  day.  Check 
port  names  and  the  ‘is  unload?*  field  to  identify  loading  and  unloading  stops  in  each  trip  for 
randomly  selected  ships.  Also  check  the  field  ‘ship  load  %  after  stop*  to  determine  when  each 
ship  is  full. 

DATA  COLLECTION  REQUIREMENTS:  Get  ship  names,  trip  numbers,  stop  ports,  and  *ls 
unload?*  data  from  table  RPTITIN. 

EVALUATION  CRITERIA:  Expect  ships  that  are  lightly  loaded  at  the  beginning  of  a  trip  to 
make  additional  loading  stops.  Any  ship  may  make  multiple  unloading  stops,  depending  on 
cargo  destinatlon(s). 
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GDAS  IV&V  TEST  CASE  #  2-47 


IV&V  ISSUE:  Analyst  control  of  closure  criteria. 

GDAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GDAS  SDS  para  5.16. 

REQUIREMENT  STATEMENT:  Calculation  of  closure  dates  are  based  on  user-specified 
delivery  percentages  by  requirement  type,  and  are  computed  automatically  at  the  end  of  the 
model  process.  Qosure  dates  are  computed  at  various  levels  including  UlC,  movement 
requirement,  unit  match  code,  and  requirement  TPSN  for  major  unit  closure. 

TEST  OBJECTIVE:  Use  GDAS  control  parameters  to  compute  unit  closures  at  different  levels 
such  as  UlC  versus  major  unit. 

TEST  PROCEDURES:  Enter  predetermined  values  for  ‘closure  required  cargo  %*  and  for 
‘closure  required  PAX  %'  for  a  selected  requirement  type  in  table  REQTYPE.  Calculate  the 
quantities  of  cargo  and  PAX  that  must  be  delivered  to  achieve  closure  for  a  randomly  selected 
requirement  of  this  type  in  table  REQUIRE.  Make  a  run  and  sum  the  cargo  quantity  delivered 
up  to  the  computed  closure  day  in  table  RPTREQ  for  the  preselected  requirement.  Compare 
the  precomputed  closure  quantities  with  the  sums  from  table  RPTREQ. 

DATA  COLLECTION  REQUIREMENTS:  Requirement  type  for  test  from  table  REQTYPE. 
Cargo  and  PAX  quantities  from  table  REQUIRE.  Computed  closure  date  and  cargo  (PAX) 
quantities,  from  table  RPTREQ. 


EVALUATION  CRITERIA:  Precomputed  closure  quantities  should  match  the  summed 
quantities  as  of  the  computed  closure  day. 
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IV&V  ISSUE:  Display  of  cargo  delivery  profiles  over  time. 


GDAS  SUBSYSTEM:  Database. 

REQUIREMENT  SOURCE:  GDAS  SDS  para  4.3.2. 

REQUIREMENT  STATEMENT;  GDAS  results  consists  of  graphical  and  tabular  outputs.  The 
tabular  outputs  include  cargo  delivery  dates,  deviation  of  delivery  date  from  RDD  for  each 
package,  and  the  amount  of  cargo  in  each  category  processed.  Graphical  outputs  include  bar 
graphs  and  line  graphs  showing  profiles  of  required  versus  delivered  cargo  by  cargo  category 
for  each  node;  daily  shortfall  in  ammunition,  resupply.  POL,  and  unit  equipment  for  each  POD; 
and  a  Gantt  chart  depicting  the  major  combat  unit  closure  profiles. 


TEST  OBJECTIVE:  Confirm  that  delivery  of  cargo  at  destination  can  be  readily  reviewed  by 
users  at  various  levels  of  aggregation. 


TEST  PROCEDURES:  Use  the  Check  Results  menu  and  the  Report  menu  under  the 
Transportation  Model  menu  to  review  the  standard  output  tables  and  charts  showing  cargo 
delivery  profiles.  Query  table  RPTREQ  to  determine  the  type  of  information  available  for  ad  hoc 
reports  or  calculations. 

DATA  COLLECTION  REQUIREMENTS:  Output  data  from  any  GDAS  scenario  can  be  used  to 
perform  this  test 

EVALUATION  CRITERIA:  As  a  minimum,  cargo  delivery  profiles  should  be  available  by  major 
units  and  by  requirement  ID. 
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IV&V  ISSUE:  Utilization  of  lift  assets  over  time. 

GDAS  SUBSYSTEM:  Database. 

REQUIREMENT  SOURCE:  GOAS  SDS  para  5.16. 

REQUIREMENT  STATEMENT:  Various  MOEs  will  be  incorporated  into  the  GDAS  prototype 
through  the  development  of  useful  queries  which  are  erthanced  by  graphical  illustrations. 

These  include  detailed  ship  itineraries  including  port  visits  and  cargo  load/unload  activities; 
detailed  port  activities  including  ship  arrivals  and  cargo  load/unload  dates;  and  summary  totals 
of  ships  and  aircraft  used. 

TEST  OBJECTIVE:  Determine  whether  the  GDAS  FD  output  requirements  for  lift  asset 
utilization  are  met  by  GDAS  output.  (See  test  3-74.) 

TEST  PROCEDURES:  Examine  data  in  tables  RPTITIN,  RPTREQ,  RPTVEHDY,  and 
RPTVEHTYPE  to  determine  whether  all  data  required  by  the  FD  is  present. 

DATA  COLLECTION  REQUIREMENTS:  Output  data  from  any  GDAS  simulation  can  be  used 
to  perform  this  test. 

EVALUATION  CRITERIA:  All  required  data  should  be  easily  accessible  to  the  analyst. 
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IV&V  ISSUE:  Compare  summary  tables  with  raw  data. 

GDAS  SUBSYSTEM:  Database. 

REQUIREMENT  SOURCE:  GDAS  SOS  para  5.16. 

REQUIREMENT  STATEMENT:  Comprehensive  details  of  the  scheduling  results  are  stored  in 
the  output  database.  The  analyst  can  query  out  any  measure  of  closure  or  delivery 
effectiveness  desired,  ranging  from  summary  totals  down  to  the  UlC  level.  Additionally,  CAA 
defined  standardized  queries  and  reports  for  major  unit  ciosure,  as  well  as  total  delivery 
summary  profiles,  will  be  developed. 

TEST  OBJECTIVE:  Compare  the  results  of  ad  hoc  queries  on  raw  GDAS  output  data  with 
values  from  the  standard  summary  data  reports  provided  in  the  GDAS  data  base  for  the 
following  MOEs: 

o  Ship  utilization 
o  Aircraft  utilization 
o  Cargo  deliveries 
o  Cargo  lateness. 

TEST  PROCEDURES:  Examine  the  data  provided  in  each  of  the  standard  reports  described 
above.  Trace  the  source  of  several  data  items  back  to  the  tables  containing  the  raw  data 
(using  the  GDAS  data  dictionary).  Use  ad  hoc  queries  to  perform  the  same  types  of  operations 
on  the  raw  data. 


DATA  COLLECTION  REQUIREMENTS:  To  be  determined.  Depends  on  the  data  available  In 
the  standard  reports. 

EVALUATION  CRITERIA:  Results  of  ad  hoc  queries  should  be  the  same  as  in  the  standard 
GDAS  output  reports. 
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GOAS  IV&V  TEST  CASE  #  2-51 


IV&V  ISSUE:  Hourly  output  on  port  activities. 


GDAS  SUBSYSTEM:  Database. 


REQUIREMENT  SOURCE:  GOAS  SDS  para  2.2. 1.1. 


REQUIREMENT  STATEMENT:  Output  involving  time  will  be  precise  to  the  nearest  day. 
although  internal  airlift  and  sealift  time  calculations  will  be  performed  on  an  hourly  basis.  The 
accuracy  of  the  input  data  is  not  sufficient  to  yield  precision  greater  than  one  day  (e.g.,  when  a 
unit  is  "ready  to  load"  is  not  really  known  even  to  the  nearest  day). 

TEST  OBJECTIVE:  Track  the  activities  of  a  specific  GDAS  entity  (cargo,  lift  asset,  or  facility)  in 
sufficient  detail  to  determine  what  it  was  doing  at  any  point  in  a  simulation  run.  Examples: 

0  Lift  vehicle  itinerary 
o  Port  facility  activities  (berths,  etc.) 
o  Cargo  movement  itinerary. 

TEST  PROCEDURES:  Not  applicable.  Tables  FACEVNT  and  RPTFACIL  show  the  day  at 
which  a  change  in  facility  resources  or  capacity  changes.  All  GDAS  time  oi'^put  is  in  units  of 
days,  which  makes  it  impossible  to  analyze  hourly  changes. 

DATA  COLLECTION  REQUIREMENTS:  Not  applicable.  According  to  the  GDAS  SDS.  hourly 
output  on  any  activity  in  the  GOAS  simulation  is  explicitly  excluded  from  the  design. 


EVALUATION  CRITERIA:  Not  applicable.  According  to  the  GDAS  SOS,  hourly  output  on  any 
activity  in  the  GOAS  simulation  is  explicitly  excluded  from  the  design. 
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IV&V  ISSUE:  Precision  of  GDAS  caicuiations. 


GDAS  SUBSYSTEM:  Database/Transportation  Model. 


REQUIREMENT  SOURCE:  GDAS  SDS  para  2.2.1. 1. 


REQUIREMENT  STATEMENT:  Internal  calculations  will  have  precision  to  produce  a  minimum 
five  significant  digits  of  output.  Additionally,  output  involving  tonnage  figures  will  be  precise  to 
the  nearest  ton  so  that  cumulative  figures  will  be  accurate.  Output  involving  time  will  be 
precise  to  the  nearest  day,  although  internal  airlift  and  sealift  time  calculations  will  be  performed 
on  an  hourly  basis. 


TEST  OBJECTIVE:  Survey  GDAS  input  and  output  data  for  indications  that  the  model  does 
not  provide  the  re..  :lred  precision.  Internal  GDAS  calculations  will  not  be  checked  in  this  test. 


TEST  PROCEDURES:  This  test  will  be  performed  concurrently  with  other  tests  that  require 
examination  or  manipulation  of  GDAS  input  and  output  data.  The  primary  indication  of 
inadequate  precision  would  be  an  instance  of  data  fields  sized  too  small  to  accept  values  that 
could  be  input  or  calculated.  If  such  problems  are  noted,  they  will  be  documented  and 
accumulated  for  evaluation  as  part  of  this  IV&V  test. 

DATA  COLLECTION  REQUIREMENTS:  Record  indications  of  inadequate  precision  while 
performing  other  IV&V  tests. 


EVALUATION  CRITERIA:  GDAS  numerical  fields  should  support  the  required  precision  (e.g., 
five  to  nine  or  more  significant  digits). 
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IV&V  ISSUE:  Turnaround  time  for  a  GDAS  simulation. 


GDAS  SUBSYSTEM:  Database/Transportation  Model. 


REQUIREMENT  SOURCE:  GDAS  SDS  para  2.2.2. 


REQUIREMENT  STATEMENT:  Simulation  run  time.  A  scenario  consisting  of  20,000 
movement  requirements  and  1,000  air/sea  nodes  and  parts  in  the  transportation  network  will 
take  approximately  4  hours  to  run  on  an  Intel  80486  machine  with  32-bit  compiled  source  code, 
depending  on  the  level  of  detail  of  the  analysis. 


TEST  OBJECTIVE:  Determine  whether  the  turnaround  time  for  an  average  GDAS  run  satisfies 
the  functional  requirement  above.  For  the  purpose  of  this  test,  an  average  run  will  be  an 
excursion  from  a  base  case  that  has  already  been  set  up  and  has  executed  successfully. 


TEST  PROCEDURES:  Timing  data  will  be  collected  from  other  tests  which  require  that  input 
data  is  changed  for  a  model  run  and  the  output  data  be  reviewed  to  assess  the  effect  of  the 
Input  changes.  The  tests  to  be  used  for  this  purpose  will  be  selected  before  their  execution. 
Clock  time  will  be  noted  at  the  beginning  and  end  of  data  preparation,  at  the  beginning  and 
end  of  procedures  required  to  set  up  and  execute  a  model  run,  at  the  beginning  and  end  of  the 
model  run,  and  at  the  beginning  and  end  of  data  analysis  (including  time  for  printouts  If 
multiple  scenarios  must  be  compared).  The  times  recorded  for  at  least  five  runs  will  be  first 
summed  for  each  run,  then  averaged  across  the  runs  to  compute  a  representative  GDAS 
turnaround  time. 


DATA  COLLECTION  REQUIREMENTS:  Record  times  as  described  in  the  test  procedures. 
Note  characteristics  of  each  run  that  indicate  the  extent  of  differences  (number  of  input  data 
tables  edited,  number  of  output  reports  examined).  Note  the  nature  and  duration  of  any 
interruptions  during  each  test. 

EVALUATION  CRITERIA:  The  computed  average  turnaround  time  should  not  exceed  four 
hours.  (Notes  on  the  differences  between  timed  tests  may  be  used  to  judge  whether  a 
particular  test  should  be  considered  representative  of  GDAS  turnaround  procedures.) 
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IV&V  ISSUE:  Maximum  size  of  GDAS  depioyment  scenarios. 

GOAS  SUBSYSTEM:  Data  Base.  Transportation  Model,  Presentation  and  Transportation 
Graphics. 

REQUIREMENT  SOURCE:  GOAS  FD  para  3-3.a  (not  in  SDS). 

REQUIREMENT  STATEMENT:  The  largest  scenario  will  involve  approximately  40,000 
movement  requirements,  1,300  aircraft,  1,500  ships,  30  ports  of  embarkation  (POEs),  and  60 
ports  of  debarkation  (POOs). 

TEST  OBJECTIVE:  Perform  stress  testing  at  the  maximum  required  GDAS  scenario  capacity 
for  movement  requirements,  ports,  and  strategic  lift  resources.  This  test  will  help  to  assess 
whether  large-scale  scenarios  cause  any  problems  in  running  GDAS. 

TEST  PROCEDURES:  Analyze  existing  GDAS  scenarios  to  find  one  with  large  scale 
deployments  to  multiple  theaters.  (If  none  exists,  create  one.)  Replicate  and  add  data  items  as 
required  to  reach  the  scenario  size  given  in  the  requirement  statement.  Run  the  model  (record 
run  time,  ref.  page  3-56)  and  examine  several  standard  output  measures  to  assess  whether  the 
output  appears  complete  and  normal.  If  difficulties  occur  on  the  first  attempt,  recheck  the 
referential  integrity  of  the  input  data  to  determine  whether  input  errors  caused  the  problems. 

DATA  COLLECTION  REQUIREMENTS:  The  only  data  to  be  collected  for  this  test  Is  any 
additional  data  needed  to  amplify  the  input  scenario  data.  Model  run  time  should  be  recorded 
as  a  probable  indication  of  the  maximum  run  time  expected  of  a  GDAS  scenario. 

EVALUATION  CRITERIA:  The  model  should  execute  normally  and  produce  output  showing 
appropriate  utilization  of  lift  assets  and  transportation  of  movement  requirements. 
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GPAS  iV&V  TEST  CASE  #  3-55 
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IV&V  ISSUE:  DBMS  query  response  times. 
GDAS  SUBSYSTEM:  Database. 


REQUIREMENT  SOURCE:  GDAS  SDS  para  2.2.2. 

REQUIREMENT  STATEMENT:  The  DBMS  response  time  for  a  simple  menu-driven  query  will 
be  within  IS  secoixis  for  small  tables.  When  presented  with  the  most  complex  query  using 
Structured-Query-Language  (SQL),  the  response  time  will  be  considerably  longer  depending  on 
the  table  sizes  and  key  field  cross-references. 

TEST  OBJECTIVE:  Confirm  that  the  GDAS  data  base  response  times  comply  with  the 
requirement  statement. 

TEST  PROCEDURES:  After  a  successful  model  run  of  a  multiple-theater  scenario,  go  to  the 
Query  function  of  the  GDAS  Transportation  Model.  Execute  all  queries  available  under  the 
menu  panel,  obtaining  overall  totals  as  often  as  possible.  Record  the  time  from  selection  of  a 
query  until  its  results  are  displayed  on  the  screen.  Tabulate  the  response  times  to  determine 
the  maximum  DBMS  menu-driven  query  response  time.  For  assessment  of  the  ad  hoc  query 
response  times,  the  queries  generated  to  calculate  results  should  be  timed  arxl  the  results 
tallied  to  determine  the  maximum  response  time. 

DATA  COLLECTION  REQUIREMENTS:  Record  query  response  times.  (The  nature  of  each 
query  nriay  be  optionally  recorded  for  possible  categorization  of  query  response  times.) 

EVALUATION  CRITERIA:  The  maximum  menu-driven  query  response  time  should  be  15 
seconds  or  less.  The  maximum  ad  hoc  query  response  time  should  be  5  minutes  or  less. 
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GOAS  IV&V  TEST  CASE  #  3-56 


IV&V  ISSUE:  Run  time  for  a  complex  scenario. 

GOAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GDAS  SOS  para  2.2.2. 

REQUIREMENT  STATEMENT:  A  scenario  consisting  of  20,000  movement  requirements  and 
1,000  air/sea  nodes  and  parts  in  the  transportation  network  wiil  take  approximately  4  hours  to 
run  on  an  Intel  80486  machine  with  32-bit  compiled  source  code,  depending  on  the  level  of 
detail  of  the  analysis. 

TEST  OBJECTIVE:  Confirm  that  GOAS  can  run  a  complex,  large  scale  scenario  within  the 
time  given  in  the  requirement  statement. 

TEST  PROCEDURES:  This  test  can  be  performed  concurrently  with  test  3-54.  The  additional 
step  required  for  this  test  is  to  record  the  time  at  the  beginning  of  the  model  run  and  at  the  end 
of  the  model  run.  (QUESTION:  Can  the  system  time  be  recorded  automatically?) 

DATA  COLLECTION  REQUIREMENTS:  Record  the  start  time  artd  erxl  time  for  the  model  run. 


EVALUATION  CRITERIA:  The  run  time  should  not  exceed  10  hours. 


IV&V  ISSUE:  Operation  of  the  main  menu  system. 

GDAS  SUBSYSTEM:  Menu. 

REQUIREMENT  SOURCE:  GOAS  SDS  para  2.2. 

REQUIREMENT  STATEMENT:  The  analyst,  In  interacting  with  the  system,  will  be  able  to 
make  selections  from  a  set  of  choices  on  a  menu,  and  update/change/create  data  through 
clearly  defined  data  entry  aixJ  manipulation  screens. 


TEST  OBJECTIVE:  Confirm  that  all  actions  required  to  input  and  edit  scenarios,  run  the 
transportation  model,  and  analyze  the  model  output  can  be  performed  from  the  GDAS  menu 
system. 


TEST  PROCEDURES:  Activate  each  option  in  the  initial  GDAS  menu  to  assess  their  operation. 
Menu  items  subordinate  to  the  ‘select  scenario*  option  will  be  used  repeatedly  in  other  tests 
and  discrepancies  will  be  documented  as  they  occur.  All  discrepancies  related  to  the  GDAS 
command  menu  should  be  summarized  under  this  test. 

DATA  COLLECTION  REQUIREMENTS:  Observe  operation  of  the  GDAS  menu  system  and 
record  discrepancies. 

EVALUATION  CRITERIA:  Each  menu  selection  should  perform  the  Indicated  action. 
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GOAS  IV&V  TEST  CASE  #  3-58 


IV&V  ISSUE:  Operation  of  the  transportation  model  menu  system. 

GDAS  SUBSYSTEM:  Menu. 

REQUIREMENT  SOURCE:  GOAS  SOS  para  4.1.4. 

REQUIREMENT  STATEMENT:  The  analyst  has  many  of  the  same  features  available  as  are 
present  under  the  GOAS  Movement  Requirement  Generation  Menu  (ref  SOS  paragraph  4.1.3). 
The  ‘Setup*  menu  option  also  attempts  to  reduce  the  complexity  of  the  model,  but  affects  very 
different  data  types  worth  mentioning  here.  Executing  'Setup'  displays  multi-table  form(s)  that 
prompt  for  gross  characteristics  such  as  whether  or  not  attrition  or  convoying  should  be 
modeled.  It  also  prompts  for  input  values  for  the  planning  horizon,  time  variations,  parametric 
and  stochastic  analysis  factors,  unit  closure  percentage,  and  penalty  factors. 

TEST  OBJECTIVE:  Confirm  that  all  actions  required  to  input  and  edit  scenarios,  run  the 
transportation  model,  and  analyze  the  model  output  can  be  performed  from  the  GDAS  menu 
system. 

TEST  PROCEDURES:  This  test  will  be  conducted  concurrently  with  other  tests  that  require 
use  of  the  scenario  menu  system.  Any  discrepancies  noted  during  normal  operation  of  the 
scenario  menu  selections  wilt  be  accumulated  for  this  test. 

DATA  COLLECTION  REQUIREMENTS:  Record  discrepancies  obsenred  during  GDAS  menu 
operations. 

EVALUATION  CRITERIA:  Scenario  menu  options  should  implement  the  indicated  actions. 
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IV&V  ISSUE:  Operation  of  the  utility  menu  system. 


GDAS  SUBSYSTEM:  Menu. 

REQUIREMENT  SOURCE:  GDAS  SOS  para  4.1.5. 


REQUIREMENT  STATEMENT:  The  ‘Utility*  menu  offers  an  assortment  of  system  maintenance 
related  functions  such  as  checking  data  consistency,  import,  export,  backup,  and  restore. 


TEST  OBJECTIVE:  Check  the  operation  of  ancillary  functions  provided  in  the  GDAS  utility 
menu  system  such  as  importing  and  exporting  data,  checking  the  referential  integrity  of  a 
scenario,  and  the  capability  to  backup  and  restore  data. 

TEST  PROCEDURES:  To  be  determined.  The  GDAS  Utility  menu  is  discussed  In  SDS 
paragraphs  4.1.5  and  4.2.1,  but  the  discussion  does  not  contain  sufficient  detail  to  generate 
test  procedures. 

DATA  COLLECTION  REQUIREMENTS:  To  be  determined.  No  specific  data  should  be 
required  to  perform  this  test.  Discrepancies  should  be  documented  and  reported  as  test 
results. 


EVALUATION  CRITERIA:  To  be  determined.  Menu  selections  in  the  final  GDAS  software  may 
differ  from  the  SDS  description,  but  each  menu  item  should  produce  the  indicated  response. 
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GDAS  IV&V  TEST  CASE  #  3>6a 


IV&V  ISSUE:  Help  screens  available  with  menu  Items. 
GDAS  SUBSYSTEM:  Menu. 


REQUIREMENT  SOURCE:  GDAS  SOS  para  2.2. 

REQUIREMENT  STATEMENT:  Each  screen  presented  to  the  user  will  include  help  which 
provides  sufficient  Information  to  enable  the  analyst  to  continue  with  a  desired  operation.  In 
addition,  the  User’s  Manual  will  be  on-line  to  sup^^ement  the  help  system. 

TEST  OBJECTIVE:  Confirm  that  help  screens  are  available  throughout  the  GDAS  menu 
system  and  that  the  information  they  contain  helps  the  user  to  complete  the  operation  in 
progress. 

TEST  PROCEDURES:  This  test  is  closely  related  to  the  main  menu  test.  The  designated  Help 
key  will  be  pressed  at  each  new  menu  screen  to  determine  whether  help  panels  are  available. 
The  content  of  each  available  help  panel  will  be  assessed  with  regard  to  its  helpfulness  in 
performing  the  operatlor»  available  under  the  selected  menu  panel.  References  to  the  user’s 
manual  will  be  spot-checked  to  determine  their  accuracy.  Ex^aln  the  nature  of  any 
discrepancies  encountered. 

DATA  COLLECTION  REQUIREMENTS:  Document  whether  help  panels  are  available  at  each 
menu  screen.  Record  an  assessment  of  whether  each  help  panel  is  useful.  Indicate  when 
references  to  the  user’s  manual  are  checked  and  whether  those  checked  are  accurate.  Record 
the  nature  of  discrepancies  discovered  at  any  point  in  the  test. 

EVALUATION  CRITERIA:  Help  panels  should  be  available  at  each  menu  screen.  Each  help 
panel  should  contain  reminders  or  helpful  hints  about  the  options  available  on  the  associated 
menu  screen.  References  should  be  available  to  direct  the  user  to  the  appropriate  section  of 
the  user’s  manual  for  more  information  on  each  item. 
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IV&V  ISSUE:  Woridwide  simulation  of  independent  theaters. 


GOAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GOAS  SOS  para  2.2. 

REQUIREMENT  STATEMENT:  The  model  will  include  the  capability  for  an  unlimited  number 
of  theaters  or  contingency  areas. 


TEST  OBJECTIVE:  Enter  movement  requirements  destined  for  eight  different  theaters  and 
confirm  that  GOAS  can  transport  ail  requirements. 

TEST  PROCEDURES:  Obtain  or  generate  locations  of  eight  theaters  (check  that  routes  to 
each  theater  are  available  In  GOAS  data).  Obtain  or  generate  a  set  of  movement  requirements 
destined  for  each  theater.  Run  the  model  and  check  output  reports  to  confirm  that  cargo  is 
delivered  to  each  theater. 


DATA  COLLECTION  REQUIREMENTS:  Oata  for  port  facilities  in  each  theater.  Time  phased 
data  for  movement  requirements  destined  to  each  theater.  Standard  GOAS  output  reports  of 
cargo  requirements  versus  deliveries. 

EVALUATION  CRITERIA:  Movement  requirements  should  be  delivered  to  their  respective 
theaters. 
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IV&V  ISSUE:  CONUS  mobilization  and  intratheater  delays. 


GDAS  SUBSYSTEM;  Transportation  Model. 
REQUIREMENT  SOURCE:  GDAS  SOS  para  2.2. 


REQUIREMENT  STATEMENT:  GDAS  will  simulate  movement  requirements  of  all  items  from 
origin  through  POEs,  to  and  through  POOs,  to  destinations  in  each  theater. 

TEST  OBJECTIVE:  Confirm  that  GDAS  simulates  movement  of  cargo  from  origin  to  POE  and 
from  POO  to  destination. 


TEST  PROCEDURES:  To  be  determined.  The  GDAS  SOS  states  that  the  target  lift  date  (TLO) 
considers  the  entire  movement  requirement  from  origin  to  POE,  to  and  through  POD,  to 
destination.  The  GDAS  data  dictionary  does  not  show  the  TLD  as  an  output  field,  so  it  may  not 
be  possible  to  confirm  the  transportation  time  between  origin  and  POE.  The  data  dictionary 
does  contain  fields  for  cargo  unload  date  (at  SPOD)  and  cargo  delivery  date  (at  destination), 
so  the  difference  between  these  dates  can  be  used  to  compute  intertheater  transportation 
delays  for  sealifted  cargo.  There  is  no  irKiicatlon  of  cargo  delivery  dates  for  airlifted  cargo. 
(NOTE:  GDAS  apparently  does  not  allow  cargo  to  form  a  queue  at  a  POE.) 

DATA  COLLECTION  REQUIREMENTS:  For  each  cargo,  obtain  the  distance  from  origin  to 
POE  and  from  POD  to  destination.  Obtain  marry-up  times  from  table  THTRREQ.  Compute  the 
difference  between  the  TLO  (if  available)  and  the  Cargo  Load  Day  (table  RPTITIN)  as  CONUS 
movement  time.  Compute  the  difference  between  the  Cargo  Unload  Day  and  Cargo  Delivery 
Day  (table  RPTITIN)  as  the  intratheater  movement  time. 


EVALUATION  CRITERIA:  CONUS  arxl  intratheater  movement  times  should  be  proportional  to 
the  distances  traveled  to  POE  arKl  from  POO.  intratheater  times  should  also  include  marry-up 
delay  days. 
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IV&V  ISSUE:  Dynamic  generation  of  medical  evacuation,  noncombatant  evacuation  (NEO), 
and  retrograde  cargo. 


GDAS  SUBSYSTEM:  Transportation  Model. 


REQUIREMENT  SOURCE:  GDAS  FD  para  3-4.b.(3)(c)4.h  (not  in  SDS). 

REQUIREMENT  STATEMENT:  Retrograde  cargo  (as  a  function  of  number  of  soldiers  in 
theater)  will  be  generated  for  each  POD  for  return  to  CONUS.  Such  retrograde  movement 
requirements  will  include  the  categories  of:  casualties,  captured  enemy  equipment,  US 
equipment  not  repairable  in  theater,  noncombatant  emergency  evacuation,  and  prisoners  of 
war.  Rates  used  for  generation  of  such  retrograde  movement  requirements  will  be  easily 
changed  by  the  analyst. 

TEST  OBJECTIVE:  Confirm  that  GDAS  has  the  capability  to  dynamically  generate,  schedule, 
and  transport  medic£il  evacuation  patients,  noncombatants,  and  retrograde  cargo  based  on  the 
number  of  soldiers  in  a  theater. 


TEST  PROCEDURES:  To  be  determined.  The  GDAS  SDS  and  program  design  language  do 
not  describe  any  mechanism  for  moving  cargo  from  theaters  to  CONUS.  The  only  evidence 
that  such  cargo  has  been  considered  is  in  the  GDAS  data  dictionary.  The  description  of  the 
Cargo  Category  data  field  (table  CARGOCAT)  indicates  that  movement  requirements  may 
include  Medivac  and  NEO  cargo  categories. 

DATA  COLLECTION  REQUIREMENTS:  No  supporting  data  available  in  GDAS  at  this  time. 

EVALUATION  CRITERIA:  To  be  determined.  Criteria  should  be  based  on  the  methodology 
and  factors  used  for  dynamic  generation  of  medical  evacuation,  NEO,  and  retrograde  cargo. 
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IV&V  ISSUE:  Weighting  of  cargo  movement  versus  lift  asset  utiiization. 


GDAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GOAS  SDS  para  2.2. 

REQUIREMENT  STATEMENT:  The  simulation  will  attempt  to  satisfy  the  following  goals: 
o  deploy  units  to  arrive  not  later  than  (NLT)  the  unit’s  ROD; 

o  deploy  resupply  cargo  to  arrive  no  later  than  (NLT)  the  resupply’s  ROD,  and  not  earlier 
than  the  unit  itself; 

o  maximize  utilization  of  lift  capacity. 

The  analyst  will  have  the  option  of  altering  scheduling  priorities  by  modifying  the  simulation 
ROD. 


TEST  OBJECTIVE:  Confirm  that  GDAS  can  be  used  to  analyze  both  transportation  system 
capacity  and  lift  resource  allocation  studies. 


TEST  PROCEDURES:  To  be  determined.  The  SDS  (para  5.15)  provides  a  general  description 
of  cost  (penalty)  factors,  benefit  factors,  and  other  parameters  designed  to  control  these  GDAS 
functions.  The  test  procedures  will  be  established  by  one  of  two  methods: 

o  If  sufficient  detail  regarding  the  use  of  scheduling  guidance  and  control  parameters  is 
provided  in  the  Detailed  Algorithm  Specification  and  User's  Manual  to  be  delivered  by  the 
model  developers,  test  procedures  will  be  based  on  that  information. 

o  An  iterative  testing  process  can  be  used,  first  executing  a  simulation  experiment  designed 
to  screen  the  effects  of  the  factors  identified  as  scheduling  guidance  arid  control 
parameters.  The  results  of  the  screening  experiment  will  then  provide  a  basis  for 
selecting  arxJ  developing  further  tests. 

DATA  COLLECTION  REQUIREMENTS:  To  be  determined.  The  primary  data  required  for  this 
test  will  be  model  control  parameters,  cargo  delivery  profiles,  and  lift  asset  utilization. 

EVALUATION  CRITERIA:  To  be  determined.  Evaluation  of  results  from  this  test  will  ultimately 
depend  on  the  GOAS  capability  for  analysts  to  control  the  balance  between  achieving  closure 
goals  and  maximizing  lift  resource  utiiization. 
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IV&V  ISSUE:  Varia'  '.e  cargo  priority  among  theaters. 

GOAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  QDAS  SDS  para  5.15. 

REQUIREMENT  STATEMENT:  The  major  criteria  for  sorting  cargos  is  the  Target  Lift  Date 
(TLO)  calculated  during  the  planning.  Among  ail  cargos  with  the  same  TLO,  the  analyst  can  set 
the  movement  priority  to  ensure  the  most  important  movements  have  the  best  chance  of 
obtaining  transportation  resources. 

TEST  OBJECTIVE:  Confirm  that  GDAS  allows  analysts  to  specify  a  desired  priority  order  for 
movement  requirements  destined  to  a  particular  theater. 

TEST  PROCEDURES:  Select  or  generate  a  scenario  that  results  in  a  quantity  of  late  cargo  to 
more  than  one  theater.  Query  tables  NODE  (fields  Node  Name,  Theater),  DESTIN  (field 
Destination),  and  REQUIRE  (field  Destination)  to  identify  all  movement  requirements  destined  to 
one  of  the  theaters.  Edit  the  Priority  Order  field  in  table  REQUIRE  so  that  a  requirement  that 
was  late  has  a  higher  priority  than  some  requirement  that  was  delivered  on  time  within  the 
selected  theater.  Rerun  the  scenario  to  determine  whether  the  priority  changes  affected  only 
the  selected  theater. 

DATA  COLLECTION  REQUIREMENTS:  Cargo  delivery  dates  and  cargo  lateness  by  theater. 

EVALUATION  CRITERIA:  Cargo  delivery  dates  for  the  selected  theater  should  result  in  earlier 
delivery  (less  lateness)  of  the  requirement  set  to  higher  priority.  Results  for  other  theaters 
should  not  be  affected 


IV&V  ISSUE:  Effectiveness  of  the  ‘look  ahead'  scheduling  window. 

GDAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GDAS  SDS  para  5.15. 

REQUIREMENT  STATEMENT:  The  primary  variable  for  setting  a  ‘look  ahead'  capability  is  the 
scheduling  horizon.  The  scheduling  horizon  defines  a  moving  time  window  relative  to  the 
current  simulation  day  in  the  model,  such  that  only  cargos  having  a  TLO  within  the  scheduling 
horizon  time  window  are  considered  for  scheduling  on  that  simulation  day.  When  the  TLO  of  a 
cargo  fails  within  the  scheduling  horizon,  the  model  evaluates  a  large  number  of  candidate  ship 
or  aircraft  assignments  for  that  cargo. 

TEST  OBJECTIVE:  Confirm  that  GDAS  allows  analysts  improve  measures  such  as  lift  asset 
utilization  (i.e.,  percent  fill)  by  extending  the  schediding  time  window. 

TEST  PROCEDURES:  To  be  determined  (see  page  3-64).  The  effectiveness  of  the  GDAS 
look-ahead  window  In  affecting  either  cargo  delivery  or  lift  asset  utilization  Is  probably  directly 
coupled  to  the  use  of  other  scheduling  guidance  and  control  factors. 

DATA  COLLECTION  REQUIREMENTS:  Primary  data  for  this  test  will  include  cargo  delivery 
measures  (unit  closures,  total  delivered  over  time,  etc.)  and  lift  asset  utilization  measures 
(vehicle  activity  over  time,  percent  fill,  etc.). 

EVALUATION  CRITERIA:  To  be  determined.  The  general  criterion  for  this  test  is  whether 
increasing  the  scheduler’s  look  ahead  window  causes  an  improvement  in  the  measure  of 
effectiveness  being  examined. 


IV&V  ISSUE:  Dynamic  reallocation  of  sealift  assets. 

GDAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GDAS  SDS  para  5.4.6. 

REQUIREMENT  STATEMENT:  The  initial  availabVity  of  a  ship  is  defined  in  the  SHIPLAD  table 
either  from  a  single  start  node  or  based  on  externally  calculated  availabilities  at  individual  ports 
(if  a  ship  availability  date  is  not  specified  for  a  given  seaport,  the  availability  is  calculated  from 
the  nearest  port  that  does  have  an  availability  date). 

TEST  OBJECTIVE:  Confirm  that  excess  sealift  capacity  at  one  port  can  be  dynamically 
reallocated  to  another  port  in  GDAS. 

TEST  PROCEDURES:  To  be  determined.  The  GDAS  SDS  and  data  dictior^ry  do  not 
describe  any  capability  to  reallocate  ships  among  ports. 

DATA  COLLECTION  REQUIREMENTS:  To  be  determined.  The  necessary  data  fields  may  be 
defined  in  a  later  version  of  the  GDAS  Data  Dictionary. 

EVALUATION  CRITERIA:  To  be  determined.  Criteria  should  be  based  on  the  methodology 
and  factors  used  to  accomplish  dynamic  reallocation  of  sealift  assets. 
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GDAS  IV&V  TEST  CASE  #  3>68 


IV&V  ISSUE:  Appropriate  measures  for  compartment  loading. 

GDAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GOAS  SDS  para  5.4.6. 

REQUIREMENT  STATEMENT:  Compartment  types  are  used  to  specify  vehicle  capacity,  stow 
factors,  and  the  units  of  measure  for  defining  capacity  limits;  e.g.,  for  sealift  the  compartments 
generally  have  a  single  limiting  capacity  measure  (mton  or  TEU  for  container  compartments, 
sq.  ft.  for  RO/RO  compartments,  cBbI  for  POL  compartments,  etc.)  and  for  airlift,  the 
compartments  have  multiple,  simultaneous  limiting  capacity  measures  based  on  density  factors 
(mton,  sq.  ft.,  pax). 

TEST  OBJECTIVE:  Confirm  that  GDAS  loads  each  available  ship  compartment  with  the 
appropriate  quantity  of  cargo  according  to  the  cargo  measure,  compartment  measure,  and 
stowage  factor. 

TEST  PROCEDURES:  Identify  a  frequently  used  compartment  type  in  table  CARGLOAD.  Link 
with  tables  CARGO  and  CATMEAS  to  get  the  basic  measures  for  the  selected  cargos.  Link 
CARGLOAD  with  SHIPCAP  to  get  the  compartment  measure  and  capacity.  Check  tables 
STOWFACT  and  STOWPEN  to  get  the  stow  efficiency  for  each  cargo  category  loaded  in  the 
selected  compartment  type.  Compare  basic  cargo  quantities  loaded  against  the  compartment 
capacity  (adjusted  by  the  stow  fector).  (QUESTION:  Where  can  we  firxJ  the  conversion 
formulas  if  measures  are  mixed?  Tables  MEASURE  and  MEASCLAS  don’t  have  them.) 

DATA  COLLECTION  REQUIREMENTS:  Use  queries  in  any  existing  GOAS  scenario  to  obtain 
the  data  described  in  the  test  procedures. 

EVALUATION  CRITERIA:  The  loaded  cargo  quantities  should  not  exceed  the  vehicle 
compartment  capacity. 
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iV&V  ISSUE:  Multimodal  shipment  of  matching  requirements. 

GOAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GOAS  SOS  para  5.2. 

REQUIREMENT  STATEMENT:  The  model  design  expiicitiy  accounts  for  the  coordination  of 
multiple,  interdependent  movements  which  are  characteristic  of  DoD  intermodal  transportation, 
inciuding  cargos  which  are  reiated  by  precedence  sequencing  (e.g.,  a  muttimodai  staged 
movement  in  which  an  airlift  leg  depenids  on  a  prior  s^ift  leg),  or  assembly  dependency  (e.g., 
multiple  air/sea  or  POMCUS  movements  which  must  marry  up  at  a  marshalling  or  staging 
location  before  moving  forwar-  or  balanced  force  links  (e.g.,  CS/CSS/supply  movements 
which  are  assigned  to  support  a  combat  unit). 

TEST  OBJECTIVE:  Confirm  that  GOAS  has  the  capability  to  schedule  interdependent  cargos 
for  synchronized  arrivals  at  destination. 

TEST  PROCEDURES:  Output  data  from  an  existing  GOAS  scenario  can  be  used  to  perform 
this  test.  Query  table  RPTREQ  to  identify  movement  requirements  that  have  both  cargo  and 
PAX  with  the  same  ROD.  Link  RPTREQ  with  tables  CARGO  and  RPTITIN  to  get  the  cargo 
delivery  dates  for  all  cargos  associated  with  each  selected  requirement. 

DATA  COLLECTION  REQUIREMENTS:  Required  data  is  described  In  the  test  procedures. 

EVALUATION  CRITERIA:  Cargo  and  PAX  belonging  to  the  same  movement  requirement 
should  be  delivered  to  destination  on  the  same  date. 


GOAS  iV&V  TEST  CASE  #  3-70 


IV&V  ISSUE:  Hourly  time  step  for  aircraft  activities. 

GDAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GOAS  SOS  para  2.2. 

REQUIREMENT  STATEMENT:  The  model  witi  be  designed  with  the  following  functional 
capabilities:  attrition,  convoying,  canals,  mode  selection,  tracking  of  individual  ships  by  hull 
number,  ship  transport  time  step  in  days,  air  time  step  in  hours,  etc. 

TEST  OBJECTIVE:  Confirm  that  GOAS  loads/unioads  aircraft  and  simulates  their  travel  in 
hourly  time  increments. 

TEST  PROCEDURES:  Not  applicable.  GOAS  time  outputs  are  in  units  of  days  only.  Hourly 
activities  cannot  be  confirmed  from  the  available  output  data. 

DATA  COLLECTION  REQUIREMENTS:  Not  apf^icable.  Hourly  time  outputs  are  not 
available. 


EVALUATION  CRITERIA:  Not  applicable.  Hourly  time  outputs  are  not  available. 
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GDAS  IV&V  TEST  CASE  #  3-71 


^  II  ■■■■i.iii  . . ■■■ . . . I 


IV&V  ISSUE:  Constrained  aircraft  throughput  at  airports. 

GDAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GDAS  SOS  para  5.4.2. 

REQUIREMENT  STATEMENT:  Each  facility  has  cargo  or  vehicle  throughput  measures  based 
on  facility  type  and  transport  mode,  e.g.,  max  cargo  tonnage  per  day,  max  number  of  sorties 
or  vehicles  per  day,  and  maximum  on  ground  (for  airlift)  or  in  berth  (for  sealift). 

TEST  OBJECTIVE:  Confirm  that  GDAS  limits  the  number  of  aircraft  per  day  using  an  airport 
facility. 

TEST  PROCEDURES:  Query  table  STOP  in  any  GDAS  scenario  to  find  an  airport  facility  that 
is  heavily  used.  In  table  FACILITY,  change  the  Max  Vehicle  Arrivals/Hour  to  two  for  this 
airport.  Rerun  the  model  and  check  table  STOP  again  to  determine  whether  the  vehicle 
throughput  constraint  was  effective. 

DATA  COLLECTION  REQUIREMENTS:  Get  the  facility  node,  vehicle  arrive  day,  and  vehicle 
depart  day  from  table  STOP.  Get  the  facility  operating  hours/day  from  table  FACILITY. 

EVALUATION  CRITERIA:  The  number  of  aircraft  arrivals  on  a  single  day  should  not  exceed 
the  product  of  operating  hours  times  arrivals/hour. 


A-74 


IV&V  ISSUE:  Hourly  time  step  for  sealift  activities. 


GDAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GDAS  SOS  para  2.2. 

REQUIREMENT  STATEMENT:  The  model  will  be  designed  with  the  following  functional 
capabilities:  attrition,  convoying,  canals,  mode  selection,  tracking  of  individuai  ships  by  hull 
number,  ship  transport  time  step  in  days,  air  time  step  in  hours,  etc. 


TEST  OBJECTIVE:  Confirm  that  GDAS  can  represent  ship  activities  with  one  hour  time 
increments  when  desired. 


TEST  PROCEDURES:  Not  applicable.  GDAS  time  outputs  are  in  units  of  days.  It  is  not 
possible  to  confirm  hourly  activities  using  the  available  data. 


DATA  COLLECTION  REQUIREMENTS:  Not  applicable. 
EVALUATION  CRITERIA:  Not  applicable. 
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IV&V  ISSUE:  Constrained  ship  throughput  at  seaports. 


GOAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GOAS  SOS  para  5.4.2. 

REQUIREMENT  STATEMENT:  Each  facility  has  cargo  or  vehicle  throughput  measures  based 
on  facility  type  and  transport  mode,  e.g.,  max  cargo  tonnage  per  day,  max  number  of  sorties 
or  vehicles  per  day,  and  maximum  on  ground  (for  airlift)  or  in  berth  (for  sealift). 


TEST  OBJECTIVE:  Confirm  that  GOAS  limits  the  number  of  ships  per  day  using  a  seaport 
facility. 

TEST  PROCEDURES:  Query  table  STOP  in  any  GOAS  scenario  to  find  a  seaport  facility  that 
is  heavily  used.  In  table  FACILITY,  change  the  Max  Vehicles  in  Facility  to  two.  Rerun  the 
model  to  determine  whether  the  vehicle  throughput  constraint  was  effective.  (See  test  2-31 .) 

DATA  COLLECTION  REQUIREMENTS:  Get  the  facility  node,  vehicle  arrive  day,  and  vehicle 
depart  day  from  table  STOP. 


EVALUATION  CRITERIA:  There  should  not  be  more  than  two  ships  at  the  selected  seaport 
facility  on  any  one  day. 
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IV&V  ISSUE:  Traceability  of  individual  lift  assets. 


GDAS  SUBSYSTEM:  Database. 

REQUIREMENT  SOURCE:  GDAS  SDS  para  5.16. 

REQUIREMENT  STATEMENT:  Various  MOEs  will  be  incorporated  Into  the  GDAS  prototype 
through  the  development  of  useful  queries  which  are  enhanced  by  graphical  illustrations. 

These  include  detailed  ship  itineraries  including  port  visits  and  cargo  load/unload  activities; 
detailed  port  activities  including  ship  arrivals  and  cargo  load/unload  dates;  and  summary  totals 
of  ships  and  aircraft  used. 


TEST  OBJECTIVE:  Determine  whether  the  GDAS  FD  output  requirements  for  iift  asset 
utilization  are  met  by  GDAS  output. 


TEST  PROCEDURES:  Examine  data  in  tables  RPTITIN.  RPTREQ,  RPTVEHDY,  and 
RPTVEHTYPE  to  determine  whether  all  data  required  by  the  FD  is  present.  (See  test  2-49.) 

DATA  COLLECTION  REQUIREMENTS:  Output  data  from  any  GDAS  simulation  can  be  used 
to  perform  this  test. 


EVALUATION  CRITERIA:  All  required  data  should  be  easily  accessible  to  the  analyst. 
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IV&V  ISSUE:  Interface  with  existing  force  models. 
GDAS  SUBSYSTEM:  Database. 


REQUIREMENT  SOURCE:  GDAS  SDS  para  2.2. 

REQUIREMENT  STATEMENT:  The  DBMS  will  be  structured  to  permit  interface  with  related 
existing  and  future  models. 

TEST  OBJECTIVE:  Confirm  that  GDAS  has  the  capability  to  produce  output  files  that  are 
formatted  for  direct  transfer  to  FORCEM  and  CEM. 


TEST  PROCEDURES:  This  test  can  be  performed  from  any  GDAS  scenario  output.  The 
GDAS  SDS  description  of  the  Database  Subsystem  (para  4.2.1)  states  that  the  Utilities  Menu, 
accessed  from  the  GDAS  Main  Menu,  has  an  export  capability  that  will  automatically  generate 
queries  and  format  output  files  for  input  into  CAA  combat  models.  First  the  Transfer  utility  must 
be  used  to  transfer  data  from  a  scenario  to  a  REFERENCE  directory.  Then  the  FORCEM  or 
CEM  Export  utility  can  format  output  files  for  input  into  the  combat  models. 

DATA  COLLECTION  REQUIREMENTS:  Obtain  a  specification  of  the  content  and  format  of 
GDAS  data  required  for  input  to  FORCEM  and  to  CEM.  Export  GDAS  output  for  each  model  to 
be  compared  with  the  data  specifications. 

EVALUATION  CRITERIA:  The  GDAS  export  files  should  precisely  match  the  FORCEM  and 
CEM  data  specifications. 


GDAS  IV&V  TEST  CASE  #  3-76 


IV&V  ISSUE:  Selectable  chart  b  pe  for  GOAS  output. 

GOAS  SUBSYSTEM:  Presentation  Graphics. 

REQUIREMENT  SOURCE:  GDAS  SOS  para  2.2. 

REQUIREMENT  STATEMENT:  The  graphics  capability  will  be  linked  with  the  DBMS  and  will 
allow  t:ie  user  to  select  chart  type  to  include  line,  pie,  and  bar  charts. 

TEST  OBJECTIVE:  Determine  the  degree  of  flexibility  available  to  analysts  while  preparing 
charts  in  the  GDAS  interactive  graphics  package. 

TEST  PROCEDURES:  To  be  determined.  The  GDAS  SDS  does  not  contain  sufficient 
information  on  the  GOAS  interactive  graphics  package  to  develop  test  procedures. 

DATA  COLLECTION  REQUIREMENTS:  To  be  determined.  Almost  any  set  of  data  in  GOAS 
output  could  be  selected  for  this  test. 

EVALUATION  CRITERIA:  The  GOAS  interactive  graphics  package  should  allow  analysts  to 
select  the  type  of  chart  used  to  present  data  as  described  in  the  requirement  statement. 
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GDAS  IV&V  TEST  CASE  #  3-77 


IV&V  ISSUE:  Capability  to  add  te}(t  to  charts. 

GDAS  SUBSYSTEM:  Presentation  Graphics. 

REQUIREMENT  SOURCE:  GDAS  SOS  para  4.2.2. 

REQUIREMENT  STATEMENT:  The  presentation  graphics  package  will  provide  options  for 
screen  definitions  and  attributes,  hardcopy  output,  and  saving  the  charts  for  full  customization 

TEST  OBJECTIVE:  Confirm  that  analysts  can  annotate  GDAS  charts  with  text  in  the 
interactive  graphics  package. 

TEST  PROCEDURES:  Use  data  from  an  existing  GDAS  scenario  to  plot  a  chart  and  annotate 
the  chart  with  inserted  text.  Detailed  information  on  use  of  the  interactive  graphics  package  is 
needed  to  develop  detailed  test  procedures. 

DATA  COLLECTION  REQUIREMENTS:  Data  from  any  GDAS  scenario  can  be  used  for  this 
test. 

EVALUATION  CRITERIA:  The  GDAS  interactive  graphics  package  should  allow  the  user  to 
insert  text  onto  a  chart  while  it  is  being  built  or  after  it  is  completed. 
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IV&V  ISSUE:  Capability  to  import  graphics  into  charts. 

GDAS  SUBSYSTEM:  Presentation  Graphics. 

REQUIREMENT  SOURCE:  GDAS  SDS  para  4.2.2. 

REQUIREMENT  STATEMENT:  The  presentation  graphics  package  will  provide  options  for 
screen  definitions  and  attributes,  hardcopy  output,  and  saving  the  charts  for  full  customization. 
(The  Presentation  Graphics  Subsystem  diagram  in  SDS  Figure  4-9  indicates  a  capability  to 
‘insert  graphics.*) 

TEST  OBJECTIVE:  Confirm  that  analysts  can  annotate  GDAS  charts  with  imported  graphics  in 
the  interactive  graphics  package. 

TEST  PROCEDURES:  Obtain  graphics  files  in  a  format  compatible  with  the  GDAS  interactive 
graphics  package  (e.g.,  PIC,  CGM).  Use  an  existing  GDAS  scenario  to  develop  a  chart  and 
add  a  graphic  to  the  chart.  Detailed  information  on  use  of  the  interactive  graphics  package  is 
needed  to  develop  detailed  test  procedures. 

DATA  COLLECTION  REQUIREMENTS:  Obtain  graphics  files  specified  by  CAA  for  Insertion 
into  a  GDAS  chart.  Data  from  any  GDAS  scenario  can  be  used  to  develop  the  test. 

EVALUATION  CRITERIA:  The  GDAS  Interactive  graphics  package  should  allow  the  user  to 
insert  graphics  from  other  sources  onto  a  GDAS  chart  while  it  is  being  built  or  after  tt  is 
completed. 


IV&V  ISSUE:  Control  of  chart  headings,  legend,  and  layout. 


GDAS  SUBSYSTEM:  Presentation  Graphics. 


REQUIREMENT  SOURCE:  GDAS  SOS  para  2.2. 

REQUIREMENT  STATEMENT:  The  graphics  capability  will  allow  the  user  to  define  headings, 
legend,  layout,  axis  scale,  labels,  text,  etc. 


TEST  OBJECTIVE:  Determine  the  degree  of  flexibiiity  available  to  analysts  while  preparing 
charts  in  the  GDAS  Interactive  graphics  package. 


TEST  PROCEDURES:  Use  data  from  an  existing  GDAS  scenario  to  develop  a  chart  (or  make 
a  copy  of  an  existing  chart).  Experiment  with  changes  in  the  chart  title,  axis  labels,  legends, 
data  symbols,  etc.  Save  and  print  several  versions  of  the  chart 

DATA  COLLECTION  REQUIREMENTS:  Data  from  any  GDAS  scenario  can  be  used  for  this 
test. 


EVALUATION  CRITERIA:  The  GDAS  interactive  graphics  package  should  allow  the  user  to 
control  the  content  size,  position,  and  orientation  of  chart  headings  and  legends. 
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iV&V  ISSUE:  Capability  to  Interactively  preview  and  edit  output  charts. 


GOAS  SUBSYSTEM:  Presentation  Graphics. 


REQUIREMENT  SOURCE:  GDAS  SDS  para  2.2. 

REQUIREMENT  STATEMENT:  The  graphics  capability  will  be  linked  with  the  DBMS  and  will 
allow  the  user  to  enter/edit  chart  data. 

TEST  OBJECTIVE:  Confirm  that  the  GOAS  interactive  graphics  package  allows  analysts  to 
preview  a  chart  as  it  will  be  printed  and  select  alternate  parameters  to  achieve  the  desired  data 
presentation. 

TEST  PROCEDURES:  This  test  can  be  performed  concurrently  with  test  #  3-79.  The  changes 
to  be  made  should  Indude  the  chart  type  and  data  content.  Printed  charts  should  be 
compared  with  the  screen  preview. 


DATA  COLLECTION  REQUIREMENTS:  Use  data  from  any  existing  GDAS  scenario  for  this 
test. 


EVALUATION  CRITERIA:  The  GDAS  interactive  graphics  package  should  provide  accurate 
screen  previews  of  charts  to  be  printed. 
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IV&V  ISSUE:  Capability  import  and  edit  data  for  output  charts. 


GDAS  SUBSYSTEM:  Presentation  Graphics. 
REQUIREMENT  SOURCE:  GDAS  SDS  para  4.2.2. 


REQUIREMENT  STATEMENT:  The  Presentation  Graphics  Subsystem  integrates  directly  with 
the  database  via  the  query  menu  functions. . .  in  addition,  the  graphics  package  can  be  used 
in  a  stand-alone  mode  to  prepare  complete  customized  presentations. 


TEST  OBJECTIVE:  Confirm  that  GDAS  allows  analysts  to  combine  any  desired  GDAS  output 
data  from  multiple  scenarios  on  a  single  chart  and  manipulate  it  for  effective  presentation. 


TEST  PROCEDURES:  For  test  purposes  it  Is  sufficient  to  demonstrate  that  data  from  two 
GDAS  scenarios  can  be  combined  on  a  single  chart.  Select  an  IV&V  test  that  requires  a  base 
case  run  and  an  excursion  run.  Identify  the  data  related  to  the  MCE  evaluated  in  the  test. 

Enter  the  presentation  graphics  subsystem  and  extract  MCE  data  from  both  the  base  case  and 
excursion  outputs.  Graph  the  two  sets  of  data  on  one  chart  for  comparison.  Use  the  editing 
features  of  the  presentation  graphics  package  to  put  the  MCE  data  in  summary  form  and  graph 
the  reduced  data  on  a  new  chart.  Detailed  information  on  use  of  the  interactive  graphics 
package  is  needed  to  develop  detailed  test  procedures. 

DATA  COLLECTION  REQUIREMENTS:  Obtain  comparable  output  data  from  two  GDAS  runs 
to  be  plotted  in  a  single  graph. 


EVALUATION  CRITERIA:  The  user  should  be  able  to  Import  data  from  any  selected  GDAS 
scenario  and  manipulate  it  in  the  Interactive  graphics  package. 
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IV&V  ISSUE:  Control  of  chart  axis  scale,  labels  and  grid  lines. 


GDAS  SUBSYSTEM:  Presentation  Graphics. 


REQUIREMENT  SOURCE:  GOAS  SOS  para  2.2. 

REQUIREMENT  STATEMENT:  The  graphics  capability  will  be  linked  with  the  DBMS  and  will 
allow  the  user  to  define  headings,  legend,  layout,  axis  scale,  labels,  text,  etc. 

TEST  OBJECTIVE:  Confirm  that  the  GDAS  interactive  graphics  system  allows  analysts  to 
control  the  presentation  of  graphed  data  in  charts. 

TEST  PROCEDURES:  This  test  can  be  performed  concurrently  with  test  #  3-79.  Experiment 
with  the  scale  and  labels  of  each  axis  and  with  available  grid  line  options  to  determine  the 
degree  of  flexibility  allowed. 

DATA  COLLECTION  REQUIREMENTS:  Document  observations  regarding  the  range  of 
options  available  in  formatting  axis  scale,  labels,  and  grid  lines. 


EVALUATION  CRITERIA:  The  user  should  have  a  flexible  range  of  options  for  formatting  axis 
scale,  labels,  and  grid  lines  in  output  charts. 
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IV&V  ISSUE:  Spreadsheet-like  manipulation  of  chart  data. 


GDAS  SUBSYSTEM:  Presentation  Graphics. 

REQUIREMENT  SOURCE:  GDAS  FO  para  3-4.d.(7)  (not  in  SOS). 


REQUIREMENT  STATEMENT:  The  interactive  graphics  package  wiil  allow  the  user  to 
manipulate  data  which  drives  the  chart  within  the  utility  with  similar  capabilities  to  spreadsheet 
programs:  calculate  values  from  cells/  sets  of  ceils,  copy,  delete,  cut,  paste  cells  or  sets  of 
cells,  buUd  macro  commands  which  wiil  perform  repetitive  functions  on  similar  data  sets. 

TEST  OBJECTIVE:  Confirm  that  the  interactive  graphics  package  has  spreadsheet-like 
capabilities  for  manipulating  data. 


TEST  PROCEDURES:  IV&V  NOTE;  Current  GDAS  development  plans  include  use  of  Quattro 
Pro  as  the  presentation  graphics  package  (including  stand  alone  use  to  customize  graphics). 
Since  Quattro  Pro  is  a  spreadsheet  package,  a  separate  test  should  not  be  necessary  to 
demonstrate  satisfaction  of  this  requirement,  if  another  package  is  used,  test  procedures 
would  depend  on  the  capabilities  of  the  package. 


DATA  COLLECTION  REQUIREMENTS:  To  be  determined. 
EVALUATION  CRITERIA:  To  be  determined. 
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IV&V  ISSUE:  Capability  to  view  animation  of  a  GOAS  simulation. 

GDAS  SUBSYSTEM:  Transportation  Graphics. 

REQUIREMENT  SOURCE:  GDAS  SDS  para  2.2. 

REQUIREMENT  STATEMENT:  The  graphics  capability  will  be  linked  with  the  DBMS  and  will 
allow  the  user  to  view  a  world  map  consisting  of  air  and  sea  ports,  channels,  origins, 
destinations,  and  transportation  assets. 

TEST  OBJECTIVE:  Confirm  that  GDAS  allows  users  to  view  animation  of  simulated  events. 


TEST  PROCEDURES:  To  be  determined.  The  GDAS  SDS  states  that  the  Transportation 
graphics  subsystem  will  have  the  capability  to  display  GDAS  nodes,  links,  and  ship  locations  in 
a  snapshot  mode  -  no  animation.  This  capability  is  not  available  during  a  model  run.  It  is 
accessed  via  the  Check  Results  option  under  the  Transportation  Model  Menu. 

DATA  COLLECTION  REQUIREMENTS:  To  be  determined.  It  should  be  possible  to  use  any 
existing  GOAS  scenario  for  this  test. 

EVALUATION  CRITERIA:  The  user  should  be  able  to  view  a  GDAS  simulation  as  it  is 
occurring  or  write  the  animation  to  an  output  file  for  later  viewing. 


IV&V  ISSUE:  Capability  add  new  queries  to  the  menu  system. 

GDAS  SUBSYSTEM:  Database. 

REQUIREMENT  SOURCE:  GDAS  SDS  para  2.2. 

REQUIREMENT  STATEMENT:  The  capability  will  exist  for  the  analyst  to  easily  add  a  new 
type  of  query  and/or  report  to  the  menu  system.  Once  added,  the  query  and/or  report  will  be 
accessible  by  a  menu  ejection. 

TEST  OBJECTIVE:  Confirm  that  GDAS  allows  users  to  save  new  data  queries  and  access 
them  through  the  menu  system. 

TEST  PROCEDURES:  This  test  can  be  performed  concurrently  with  IV&V  test  #  3-86  that 
requires  an  ad  hoc  data  query.  Once  the  query  is  developed,  save  It  using  the  procedure 
provided  in  GDAS.  Exit  GDAS  normally  and  enter  again,  selecting  the  same  scenario.  Select 
the  ‘Use  Custom  Queries'  option  from  the  Query  menu  to  find  and  play  the  saved  query. 
(QUESTION:  Should  the  new  query  be  available  in  other  scenarios?) 

DATA  COLLECTION  REQUIREMENTS:  This  test  can  be  performed  with  any  existing  GDAS 
scenario. 

EVALUATION  CRITERIA:  The  saved  query  should  be  available  via  the  GDAS  menu  system. 


A-88 


IV&V  ISSUE:  Capability  to  generate  ad  hoc  queries  and  reports. 

GOAS  SUBSYSTEM:  Database. 

REQUIREMENT  SOURCE:  GDAS  SDS  para  2.2. 

REQUIREMENT  STATEMENT:  In  addition  to  the  capability  of  producing  standard  reports,  the 
model  will  be  supported  by  an  independent  DBMS  which  will  allow  the  analyst  to  quickly 
perform  ad  hoc  queries  concerning  particular  model  runs. 

TEST  OBJECTIVE:  Confirm  that  analysts  can  readily  retrieve,  update,  and  dispiay  GDAS  data 
without  using  the  standard  GDAS  reports. 

TEST  PROCEDURES:  Use  the  Create/Edit  option  under  the  Query  menu  of  the 
Transportation  Model  menu.  Create  arid  execute  a  query  to  produce  a  result  that  can  be 
compared  with  a  standard  output  report.  For  exampie,  all  cargo  and  PAX  quantities  associated 
with  one  movement  requirement  can  be  summed  by  measure  and  compared  with  the  input 
totals.  (NOTE:  Test  3-85  can  be  performed  at  this  point.) 

DATA  COLLECTION  REQUIREMENTS:  This  test  can  be  performed  using  any  existing  GDAS 
scenario. 

EVALUATION  CRITERIA:  The  user  should  be  aUe  to  generate  accurate  results  from  an  ad 
hoc  query. 


IV&V  ISSUE:  Capability  to  add  new  reports  to  the  menu  system. 
GOAS  SUBSYSTEM:  Database. 


REQUIREMENT  SOURCE:  GOAS  SOS  para  2.2. 

REQUIREMENT  STATEMENT:  The  capability  will  exist  for  the  analyst  to  easily  add  a  new 
type  of  query  and/or  report  to  the  menu  system.  Once  added,  the  query  and/or  report  will  be 
accessible  by  a  menu  selection. 

TEST  OBJECTIVE:  Confirm  that  users  can  generate  new  report  formats  and  save  them  for 
later  use  via  the  GOAS  menu  system. 

TEST  PROCEDURES:  To  be  determined.  The  GOAS  SOS  does  not  describe  a  procedure  to 
develop  new  reports.  Anticipate  that  one  would  first  develop  and  save  a  query  to  tabulate  the 
data  of  interest,  then  develop  and  save  a  report  that  formats  the  query  results  for  output. 

DATA  COLLECTION  REQUIREMENTS:  To  be  determined.  Almost  any  set  of  data  in  the 
GOAS  output  could  be  selected  for  this  test. 

EVALUATION  CRITERIA:  To  be  determined.  The  basic  concept  is  that  once  a  report  is  put 
into  the  GOAS  menu  system  it  should  be  available  to  produce  similar  output  for  subsequent 
model  runs. 


iV&V  ISSUE:  Output  showing  port  operations  by  date  and  time. 

GOAS  SUBSYSTEM:  Transportation  Model. 

REQUIREMENT  SOURCE:  GDAS  SDS  para  5.4.9. 

REQUIREMENT  STATEMENT:  Each  voyage  or  trip  has  an  itinerary  which  Is  defined  in  terms 
of  stops  at  ports  or  nodes.  For  each  stop,  the  output  data  includes  arrive  day,  node  or  port, 
facility  type,  depart  day,  and  whether  the  stop  is  for  unloading.  (NOTE;  Hourly  output  is 
explicitly  excluded  from  the  GOAS  design.) 

TEST  OBJECTIVE:  Confirm  that  GDAS  has  the  capability  to  analyze  the  impact  of  port 
constraints  on  a  deployment  in  sufficient  detail  to  identify  bottlenecks. 

TEST  PROCEDURES:  Query  table  RPTITiN  for  ail  records  related  to  a  specific  port  facility, 
sum  the  cargo  loaded  and  unloaded  at  the  facility  by  day  for  comparison  with  GDAS  summary 
reports  showing  cargo  delivered.  Also  check  facility  activities  in  table  RPTITIN  against  activities 
in  table  STOP  for  the  same  facility. 

DATA  COLLECTION  REQUIREMENTS:  Obtain  facility  activities  from  tables  RPTITIN  and 
STOP.  Use  GOAS  standard  cargo  delivery  output  (by  port)  to  compare  with  query  totals. 

EVALUATION  CRITERIA:  GDAS  output  files  should  give  both  the  date  and  time  of  significant 
events  (opening,  closing,  etc.). 


A-91 


IV&V  ISSUE:  Capability  to  archive  the  entire  GDAS  system. 

GOAS  SUBSYSTEM:  Utility  Menu. 

REQUIREMENT  SOURCE:  GDAS  SOS  para  4.2.1. 

REQUIREMENT  STATEMENT:  The  ‘Backup*  and  ‘Restore*  utilities  backup  and  restore 
complete  scenarios  respectively.  Once  the  analyst  chooses  either  option,  he/she  is  prompted 
for  some  information  including  the  scenario  name  and  either  tape  or  floppy  disk(s). 

TEST  OBJECTIVE:  Save  (archive)  the  GOAS  computer  programs  and  a  selected  scenario  to 
tape  or  floppy  disks  and  restore  the  system  from  the  saved  copy. 

TEST  PROCEDURES:  The  GOAS  utility  menu  can  be  used  to  save  a  GDAS  scenario,  rename 
the  scenario  directories,  then  restore  the  original  directory.  Completeness  of  the  restored  files 
can  be  confirmed  by  checking  storage  space  used  and  by  using  a  file  comparator  utility  to 
check  the  restored  directories  against  ttie  original  directories. 

Procedures  for  saving  the  GDAS  computer  programs  are  not  described  in  the  SOS.  If 
accomplished,  all  GOAS  directories  can  be  renamed  after  the  copy  is  saved.  A  file  comparator 
can  be  used  to  check  the  restored  directories  against  the  original  files. 

DATA  COLLECTION  REQUIREMENTS:  Print  or  record  the  storage  used  by  the  scenario  and 
by  selected  Individual  files  for  comparison  with  the  restored  scenario. 

EVALUATION  CRITERIA:  The  restored  scenario  should  match  the  original  scenario  in  each 
comparison. 
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IV&V  ISSUE:  DBMS  support  of  structured  query  language  (SQL). 
GDAS  SUBSYSTEM:  Database. 


REQUIREMENT  SOURCE:  None. 


REQUIREMENT  STATEMENT:  Applicability  of  this  test  must  be  determined  from  forthcoming 
GDAS  documentation.  The  GDAS  DBMS  will  be  Paradox,  but  the  SDS  description  of  the 
DBMS  is  based  on  Ingres. 

TEST  OBJECTIVE:  Confirm  that  GDAS  can  share  or  exchange  data  with  SQL-based  data 
bases. 

TEST  PROCEDURES:  Not  applicable.  The  following  excerpt  from  the  GDAS  SDS  Indicates 
that  GDAS  cannot  access  files  over  the  CAA  local  area  network  (LAN); 

'Automated  import  and  export  capabilities  are  designed  for  GDAS  for  data  transfer  to/from  9* 
track  tape  or  1 .2  MB  floppy  disks,  but  LAN  applications  or  utiiities  to  be  developed  by  CAA  for 
file  transfer  over  the  LAN  are  not  part  of  this  design.* 

IV&V  NOTE:  If  a  LAN  capability  is  developed  in  GDAS,  the  Paradox  DBMS  used  in  GDAS 
should  be  able  to  access  SQL  files  by  adding  Borland’s  SQL  Link  package  (purchased 
separately).  SQL  Link  translates  Paradox  query-by-example  screens  into  SQL  format  to  query 
remote  tables  (with  some  restrictions).  Installation  of  SQL  Link  requires  prior  installation  of  one 
of  the  following  servers: 

o  IBM  Extended  Edition  1.2  Database  Manager 
o  Microsoft  SQL  Server  Version  1.0  or  later 
o  Oracle  Server  6.0. 


DATA  COLLECTION  REQUIREMENTS:  Not  applicable.  The  need  for  this  test  must  be 
assessed  from  forthcoming  GDAS  documentatioa 

EVALUATION  CRITERIA:  Not  applicable.  The  need  for  this  test  must  be  assessed  from 
forthcoming  GDAS  documentation. 
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iV&V  ISSUE:  Automatic  classification  marking  on  system  output. 

GDAS  SUBSYSTEM:  Database. 

REQUIREMENT  SOURCE:  GOAS  SDS  para  3.4. 

REQUIREMENT  STATEMENT:  Output  of  classified  information  will  be  automatically  marked 
with  the  appropriate  classification  as  specified  by  the  analyst. 

TEST  OBJECTIVE:  Produce  GOAS  output  with  the  correct  classification  appropriately  marked. 

TEST  PROCEDURES:  Arbitrarily  change  the  classification  level  of  a  completed  GDAS  run  and 
produce  randomly  selected  standard  outputs  on  both  screen  and  hard  copy  devices.  Check 
that  the  output  is  correctly  marked  with  the  input  classification  level.  (Question:  Can  different 
reports  from  the  same  scenario  have  different  classification  levels?) 

DATA  COLLECTION  REQUIREMENTS:  This  test  can  be  conducted  with  any  existing  GDAS 
output  report. 

EVALUATION  CRITERIA:  Output  should  be  correctly  marked  with  the  input  classification 
level. 


